The obvious solution, of course, is to think things through.

Right, but doing that 50 times per day is more challenging than once, for example.

Whether you commit your code once in one batch at the end of the day or 50 times in 50 smaller chunks, you have the same amount of complexity about which to be careful. In fact it's more complex in the former case, because in the latter, for each push, you know that all the previous pushes are working.

How do you figure?

Does walking continuously for 1000km merely take 100 times longer/more effort than 10km?

Good point, but you answered your own question: the "walk then rest" algorithm will do it in linear time.

null pointer on your drink-bottle instance results in fatal runtime exception.

Pun intended?

da-da-chhhhh. you're quick ;)

Remember that a child's name should also be intention-revealing. "George" doesn't do much for you there. Consider some examples--

* Pat: one of the least intention-revealing names possible. The name is androgynous; can we assume the child is as well? Should we assume the child does not wish to buck the status quo (wishes to "stand pat")?

* George: doing better. It reveals the sex, at least. There is still the problem that it doesn't say much about what the child does.

* Paul Jr.: This is much clearer. The child's sex is clear, as well as its purpose: a lighter, faster implementation of the original Paul Graham (the original, of course, is kept around for reasons of backwards-compatibility).

To test a baby name: Imagine a second, very different baby. Will the name work for both babies?

Other examples of good baby names include mCarryOnTheFamilyName, fBiologicalImperativeToReproduce, and Buck.