Holding a Program in One's Head

[RickJ]

Here is an interesting essay about programming.  Thought I'd share.  Cheers!

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. ...

[Vince Twelve]

At one point two or three years into working on Resonance, I dreamed that I found a bug and figured out the solution to it.  When I woke up, I checked the code and it was a real bug.  I fixed it using the code I had already written in my dream.

[Ponch]

I've dreamed about coding before, but never in anything approaching a useful way. My hat's off to you, sir!

[Monsieur OUXX]

A skilled individual can certainly hold an entire program's idea and architecture and progress in his head. And there is indeed a beauty to that.

But a good programmer/designer is the one that will know how to break it down so that the project never ever ever relies on one single person. Neither during development phase nor maintenance phase.

To a certain extent, the guy who has the perfect program in his head but can't share it with anybody (because if someone touches anything it will be broken or the inventor will stop mastering it) can even be considered a bad programmer.

Let us never forget that a program is like a machine. If you build a machine on your own, without blueprint and stuff, you'll never be much more than a mad scientist. When the DeLorean got hit by a train, all got lost in a blink. Furthermore, had Doc hit his head before completion and forgotten the flux capacitor's design, all would have been lost too.

I could even argue that the same thing can be said for mathematicians: If you find a theorem but don't bother explaining around, you suck. Let us remember Fermat's laziness. It took 3 centuries to prove his so-called "easy demonstration".


In a nutshell: my personal opinion is that a "cool/good programmer" is not the one who holds everything in his head, but the one who makes the longest lasting things.
That is, not the one who will create things that will be harmonious only in his head, but instead things that will fit nicely in their entire environment.

[RickJ]

You seem to be responding to the title of the essay rather than it's content.  The essay is not about work product but rather about the problem solving process. 

For example you say

.. a good programmer/designer is the one that will know how to break it down so that the project never ever ever relies on one single person..

However, one must have a thorough and intimate understanding of the problem before it can be broken down into smaller parts.  The essay describes the process through which most professionals gain such an understanding

... 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....

It also suggests a structured methodology of breaking a problem down in to smaller pieces

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.

Just breaking a problem down any old way isn't very useful in my view.

To a certain extent, the guy who has the perfect program in his head but can't share it with anybody (because if someone touches anything it will be broken or the inventor will stop mastering it) can even be considered a bad programmer.

The essay does not say or suggest such a thing. You are mistaken to interpret the meaning in this way. The essay describes a programmer's thought process rather than his work product; they are two different things.   

Let us never forget that a program is like a machine. If you build a machine on your own, without blueprint and stuff, you'll never be much more than a mad scientist. When the DeLorean got hit by a train, all got lost in a blink. Furthermore, had Doc hit his head before completion and forgotten the flux capacitor's design, all would have been lost too.

Interesting that you make an analogy to building a machine.   I shared the same essay with my mechanical engineering colleagues and all have said that they engage in a similar thought process when they design machines (yes machines as in custom manufacturing cells).  Their work products are 3D Solid Works drawings rendered in 2D prints (blueprints & stuff).  They tell me that before they commit their ideas to drawings they first have the ideas in their heads and that they are able visualize their designs in operation.

I could even argue that the same thing can be said for mathematicians: If you find a theorem but don't bother explaining around, you suck. Let us remember Fermat's laziness. It took 3 centuries to prove his so-called "easy demonstration".

All programmers know it's good to write readable code. But you yourself are the most important reader. Especially in the beginning; a prototype is a conversation with yourself. And when writing for yourself you have different priorities. If you're writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to to read if you spread things out, like an introductory textbook. Whereas if you're writing code to make it easy to reload into your head, it may be best to go for brevity.

But who would you argue with?  Certainly not the essay! I don't know where you got this idea from; it didn't come from the essay so perhaps you already had it in your head and read the essay (I assume you did read it) with this bias and interpretation in mind.   

So then what is the point of the essay?  The author says it in this paragraph.

Perhaps it will help if more people understand that the way programmers behave is driven by the demands of the work they do. It's not because they're irresponsible that they work in long binges during which they blow off all other obligations, plunge straight into programming instead of writing specs first, and rewrite code that already works. It's not because they're unfriendly that they prefer to work alone, or growl at people who pop their head in the door to say hello. This apparently random collection of annoying habits has a single explanation: the power of holding a program in one's head.

[Tartalo]

Yeah! I have something in common with Vince Twelve! Once I woke up in the middle of the night with the code to solve a problem in my head, half asleep I wrote it on a paper and went back to bed. When I tried it next morning, much to my surprise it worked without modifications.

Unlike Vince I'm not a professional programmer and that was a new language for me, I think that this "holding the program in your head" has more to do with creativity and the way we all solve problems, than it has to do with programming proficiency. The brain doesn't really rest, and often it's necessary to distance and "stop thinking" for a while to find the solution.

For this reason, the second hint surprises me a bit, in my opinion long concentrated sessions and conscious thinking alone won't help, you need to "distract" your brain too, and this is valid for programming and any other problem-solving situation in my opinion. The problem comes when the distractions don't allow you to concentrate enough.
EDIT: Actually, the article says exactly that with other words (Note to self: stop reading in diagonal)

[SpeechCenter]

Yes, I agree that holding a program in one's head is a good description. The trait of taking a problem, breaking it down and having a clear logical representation is very important. I too enjoyed the experience of waking up with a solution to a problem from the night before, it's a very rare event, but it's truly fun.

The only thing I would object is the part about "keep rewriting your program", it says that rewriting the program yields cleaner design, but in fact ideally a clean design should prevent the requirement of rewriting a program. I prefer a modular design where you can build upon what you wrote before when introducing more features without requiring you to rewrite. You might refactor things a bit, which is ok since you cannot and should not write everything as generic, but often if one needs to rewrite their code it usually means that it wasn't good enough in the first place (or in case the requirements changed significantly then the new code is actually a solution to a completely different problem, therefore it's not really a rewrite).