There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
Programs must be written for people to read, and only incidentally for machines to execute.
> I found myself wishing to have a continue keyword [...]
> I can't recall an official reason why it isn't in the language.
Lua evolves by answering "why?" not "why not?".
I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Premature optimization is the root of all evil (or at least most of it) in programming.
Do one thing and do it well.
Make it run. Make it right. Make it fast.
The key to making programs fast is to make them do practically nothing.
I'm a huge proponent of designing your code around the data, rather than the other way around. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
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.
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.