I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step.

There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to know how to do it mentally" --- it fails miserably when debugging, precisely the time when the machine can't do it.

I've heard it phrased thus: "If you don't understand precisely what you need to do, what makes you think you can tell a computer how to do it?"

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.

> For one, all the other developers are going to make you maintain that code for the rest of your life.

Ah, if only that were the case. In reality, developers move between jobs, and bad code always becomes someone else's responsibility eventually.

Instead, it's better to understand that as a professional you should be - if not proud of your results - proud of making the best of a bad situation for whoever will inherit your codebase, be that your future self or a colleague.