In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.

Production speed is severely slowed down if one works with half-time people who have other obligations as well. This is at least a factor of four; probably it is worse.

Beware of "the real world". A speaker's apeal to it is always an invitation not to challenge his tacit assumptions.

In this respect a program is like a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced". In so doing they book that number on the wrong side of the ledger: we should always refer to "the number of lines of code spent".

Some consider the puzzles that are created by their omissions as spicy challenges, without which their texts would be boring; others shun clarity lest their work is considered trivial.

Testing shows the presence, not the absence of bugs.

Much of the excitement we get out of our work is that we don't really know what we are doing.