Getting your mind around it

Paul Graham gives an excellent inside look at programming. He calls it “Holding a Program in One’s Head”:

A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he’s working on. Mathematicians don’t answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.

I call this getting your mind around it. I don’t try to hold the whole program in my head, but rather its key objects: how they should interact; which features matter; which objects handle which requirements[1].

That’s particularly valuable at the start of a project, because initially the most important thing is to be able to change what you’re doing. Not just to solve the problem in a different way, but to change the problem you’re solving.

Your code is your understanding of the problem you’re exploring. So it’s only when you have your code in your head that you really understand the problem.

You labor to intimately understand the entire problem, even though it’s impossible. So (as he says) you must mentally explore various directions.

It’s not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you’re actively working on a program it can take half an hour to load into your head when you start work each day. And that’s in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they’re solving.

Distractions can be deadly, though I wouldn’t put it this dramatically. Programmers working in “typical office conditions” do need to get creative to carve out the mental resources they need.

Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard.

Absolutely.

Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you.

True.

Harness the power.

The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.

Today’s C++ compiler is an incredibly powerful tool. Use it. Exploit it. Harness its power. Its goal is to help you solve the problem, managing details and catching many kinds of mistakes along the way. Let it.[2]

Your code’s values. (Clarity, clarity, clarity.)

You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.

“Programming languages” sounds a bit cryptic to my ears. I prefer building blocks. The lower layers should be good building blocks for the higher ones.

Your code should be “values-oriented:”

• Your first responsibility: make your caller’s code clear.
• Your second responsibility: be as clear as possible yourself.

Trading a lower layer’s clarity for a higher layer’s is almost always the right thing to do. Your caller’s code should read like pseudo-code, marching as clearly through its sequence as possible. Same’s true for you.

How would you do it differently? (Make it so!)

Paul writes:

Keep rewriting your program. Rewriting a program often yields a cleaner design. But it would have advantages even if it didn’t: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.

It almost sounds like he’s endorsing rewriting just to warm up your fingers, but that’s not his point.

A delicate issue requiring sober judgment. There’s an obvious cost to rewriting code (your time). But there’s a cost to living with a piece of code, too (and it’s open-ended and perhaps very painful). As you learn better what it needs to do, you may need to radically change it. My bias, like Paul’s, is to make those radical changes. (And don’t blame yourself for lacking omniscience.) Yes, your boss may have a heart attack, but it could save him from one too.

I’ve rambled enough. Give Paul’s piece a read.

Via Bruce

Notes:

[1] – He agrees, saying later, “If you [build your code] right, you only have to keep the topmost layer in your head.”

[2] – I don’t mean to slight your favorite language.