I think a pencil and paper are a programmers best friend. I find it helps me work through complex logic easier when I'm debugging. I find it helps me write cleaner code when I'm tasked with something challenging. I keep a notebook next to me when coding or debugging. I try to write down my thought process when writing new code. When debugging, I write the recreate steps (if there aren't any already), and any insteresting notes about the bug while I'm tracking it down. I write down anything I think the 'fix' may impact (I also email the team about those). Basically anything and everything.

I have a similar quip that not many in my office find popular. Basically, if you can't manually test something, what makes you think you can automated the test?

I tried telling a client once, "if you can't tell me what you want, how am I supposed to make the computer do it." Wasn't very well received.

But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.

It does get a little more difficult when execution flows into code you didn't write, but you can still validate your post/pre-conditions at those boundaries.

> In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete.

That's the whole reason why you would want execute the code mentally. If you don't execute the code mentally, you might not realize that your mental model of the third-party component was incomplete to begin with. Mentally executing code is a great way to test your own assumptions.

Your mental model of the code you're reading is probably incomplete too. Just be aware of where you're less confident and then you can use different mechanisms to build that confidence when it's the most logical thing to do (running a minimal test case, or log a function return value, perhaps).

This scales up to about 10-15 lines of code before it becomes impractical in most modern imperative languages. Functional languages due to their higher level constructs get better mileage out of the technique but there is still a small practical limit to the technique.

It also doesn't work if your team isn't co-located.

What? No. If you can only scale that up to 10-15 lines of imperative code, you're writing imperative code completely wrong.