Double negative

What does this mean?
No digit characters are rejected by NumericalValidator.

Even though the quite self-descriptive NumericalValidator class name, it is unclear if the validator accepts or rejects letters or digits. This sentence is hard to understand due to the double negation, which requests an unnecessary effort from the reader (as it has to inverse the content of the sentence twice to find out the real meaning).

In a nutshell, do not ever use double negative, it's misleading and error prone.

Another classical example
I do not disagree can be translated into I agree.

The exception
Apart of poetry, the only exception I can see to this rule is when you pretend to confuse your reader or whoever are you arguing with, then it can be used as a way to obscure the message (and without lying!).
I wouldn't recommend you to do so, discussions which need treats like those are usually unhealthy as they derive in who's best at using the language and rhetorics and not at what's the best solution to the subject being discussed.

The code!
Of course, all this dissertation also applies to your code! Avoid using the negation operator in front of variables whose name is negative (either contain not in the name or use a negative word).

For example: 
!notClosed would be the same as !Open but less readable.

Conditional breakpoint and cheatpoint

Conditional checkpoints are a practical and powerful tool. Premise is simple: you setup a condition and, while debugging, execution only stops if condition is met. 

The key word here is condition, whose potential is sometimes underestimated even though the conditions input dialog is quite explicit about its options (sorry dialog pic is in Spanish):

So, a commonly missed feature is that breakpoint can stop in case a value has changed. I have no clue why people is missing this (me the first one). Maybe it's a usability problem (put the blame on them, as usual).

The second feature that is often missed it's a misuse of conditional breakpoints which I like to call conditional cheatpoints.

Think about a conditional break point as a function that is called and stops execution depending on its results. Give it an evil twist...  and you have an open door for sloppy code injection! Whatever you state in the conditional break point condition will be executed every time execution flow reaches the line with the break point. BTW, credit for conditional cheatpoints for Jordi Rodriguez, who discovered them to me.

What the hell I am using conditional cheakpoints for?

When I work with slow to compile solutions and I make a mistake which prevents code to take the execution path I would like to test, sometimes I can add a cheatpoint to force code to take the execution path I want without having to stop execution and recompiling it.

Example:

In the following screenshot you can see that I set hasStock to true in the condition breakpoint. This way, even if HasStock method has a bug which returns false by mistake I can force the execution of the stock removal code.

Guesstimate

Guesstimate is a fancy word to define a bold estimate, an estimate made without enough details, knowledge and/or time.
Real world application, when somebody (usually your boss) is pushing hard to get an estimation and doesn't accept the canonical answer (need time to think about it, can't answer without some previous checks, ....) and you finally dare to answer, then the answer must be clearly a guesstimate.

Hope you don't need it a lot!