Since I likely won't be able to attend Boostcon yet again, my $0.02 favorite "How I code rule" is: You must copy, i.e. cut and paste, the code at least once, possibly twice, before making a function out of it through refactoring. This ensure that there are at least two use cases for the function and that the requirements for the function can be tested, that the function is justified, and that it actually makes sense. When I do not do this, I often create functions that I then add new parameters to, eventually those parameters turn into a structure, the structure becomes a class and the function becomes a method of the class....through aggressive refactoring, the code ends up the same, but it just takes longer. A related sub-rule of this is to name functions nounVerb() rather than verbNoun(). For example, circleDraw() rather than drawCircle(). This took me a while to get used to and it is purely for easier recognition of refactoring situations. For example, when circleDraw(), squareDraw(), ellipseDraw() show up, it starts becoming obvious that there is an opportunity for refactoring. This might only mean that draw() becomes a method of Circle or that there is a larger relationship between the nouns. Whatever it is, I find that placing the noun first helps me see this more quickly. I think this is a great idea for a talk and if it is made available on the video site afterwards, I'd be very interested in watching it. Brian