Code generation, like drinking alcohol, is good in moderation.
If you have a procedure with ten parameters, you probably missed some.
Less than 10% of the code has to do with the ostensible purpose of the system; the rest deals with input-output, data validation, data structure maintenance, and other housekeeping.
It's easier to change the specification to fit the program than vice versa.
Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time.
If you automate a mess, you get an automated mess.
Before software should be reusable, it should be usable.
If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent."
It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.
Low-level programming is good for the programmer's soul.