Larry's Sayings Recorded 4/2/2004 after sitting in a file cabinet for 13 years 2 months. These were written one a day when while at Geophysical Corporation of America after developing a 37,000 line C++ program and not having anything particularly interesting to do anymore. The C++ program merely allowed all the software components of the semiconductor wafer stepper to talk to each other. Each of these sayings has a one or two page story behind them yet to be written. All were, pretty much, concerned with practical programming aspects. The item 1/29/91 was actually discovered when working at Young and Rubicam sometime between 1968 and 1972 when an ALGOL program accidently referenced a global variable "i" in a for loop 3 procedure calls down. It was very difficult to discover why the value of "i" was going all over the place. It is curious that after so long languages are developed which again ignore good programming style thus making programming much more error prone. Compare TCL with pascal, for instance. And yet these new styles are popular. 1/28/91 Never use i as a global. 1/29/91 Programming can be an evolution or a revolution. 1/30/91 Expect to write "new" code 3 times. 1/31/91 Never remove debugging code to produce a production version without testing that production version. 2/1/91 I just bought it, it's obsolete, it works. 2/4/91 Fix the little bugs first. They may make the big bugs harder to fix. 2/5/91 Testing a program is difficult if it has not been engineered for it. 2/6/91 The bug fix rate goes up just before it "works". 2/7/91 If you need a manual for it, it is too complicated. 2/8/91 A good product is tested. testing and repair require modification. If modification requires extensive time to rebuild then it is difficult to build a good product. Ergo, speed in development systems translates to good product. 2/11/91 There is no last bug. 2/12/91 Internal consistency checks which abort programs make them reliable when properly tested. Robust intelligent fault tolerant programs are unreliable even after testing. 2/13/91 Don't spend more time deciding whether to add a feature than it takes to add the feature. 2/14/91 Programs are out to get you. 2/15/91 If you write it twice, make it a subroutine. (8/04, microsoft seems to call this refraction these days). 2/18/91 If you use it in two different programs, put it in a library. 2/19/91 It is easier to document someone else's code. 2/20/91 Add debugging code, recompile, test, … This is called programming. 2/21/91 When debugging it is more important to form a hypothesis and test it rapidly than it is to form the correct hypothesis and take all day doing it. Knowing you are right provides insight. Knowing you are wrong provides just as much Insight if not more. Knowing something trivial is right or wrong is much more important than it seems. 2/21/91 System Design is a compromise between what you know you need and what you can't yet know about. It is wise to design a system twice because of this. In other disciplines this is called a pilot project (see Brooks, "The Mythical man Month"). 2/25/91 Keep it small, keep it simple. You can make it go faster by changing the design but you can only do this correctly if it small and simple. 2/26/91 Just before a program works perfectly it doesn't work at all. Awful problems develop just before programs starting working. 2/27/91 Never lose track of anything especially memory. Lost resources are called bugs. (Except in Lisp, of course). 2/28/01 Humiliating experiences are good for you. Think of it as a reality break. 3/1/01 After a few years you will forget the problems you had at the beginning. This makes it less likely that you can teach it. 3/4/91 It is ten times better to be able to write a section of code in ten minutes than to be able to find it in a library in ten minutes. For instance, a bubble sort might even get you a job. 3/5/91 Consider the following statements: 1) Computers only do what you tell them. 2) Computers only do what they want unless you give them absolutely no choice. Are these the same statements ? Do humans work the same way ? 3/6/91 Solving 90 % of the problem immediately can stop a flood and give experience. It can also set unrealistic precedents. It seems that poorly working systems can be improved or replaced but non existing systems do not mature at all. 3/7/91 If it isn't written down it doesn't exist. And perhaps it's just as well. 4/21/91 If you are aboard a sinking ship the last thing you would do would be to start building a new ship. The question is not whether to go forward or not but rather whether to make a headlong leap with your eyes closed or open. Do not speculate with your children. These were added over the years but I'm not sure when: 4/1/04 Do not ignore orders of magnitude. 4/2/04 Do not ignore close orders of magnitude. 4/3/03 Being right is a fine thing but not if you tell anyone. 8/27/07 Fast logging is worth it's weight in gold. 8/27/07 Fast logging might need a big disk and you are in big trouble if you get in an infinite loop.