Holding a Program in One’s Head
Paul Graham [who is obnoxiously elitist, but frequently insightful] has a new essay, “Holding a Program in One’s Head“, that is making me feel sad this morning.
“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 know that feeling so well, and I want to be back in that [non-Euclidean] space again.
(I’m fascinated by such spaces, as I’ve written before.) Currently my work is so fragmented into little bits — reading bug reports, figuring out what’s going wrong, making little tiny changes, testing them, dealing with the bureaucracy of integrating changes. It’s no one’s fault, and it’s a necessary part of finishing a large release, but I’m sick of it.
The worst thing is that I can’t even summon up the energy to focus deeply on anything else. When I’m not doing the above, I’m mostly sucking at the teat of incoming news-bites and emails. When all my unread counts hit zero I feel lost. I have any number of interesting in-progress projects I could work on, but I develop selective amnesia of them while at the keyboard, because I feel too lazy to put on those Goggles Of Omniscient Coding.
I know this will go away. But I want it to go away NOW.
“Whether or not understanding this can help large organizations, it can certainly help their competitors. The weakest point in big companies is that they don’t let individual programmers do great work. So if you’re a little startup, this is the place to attack them. Take on the kind of problems that have to be solved in one big brain.”
October 3rd, 2007 at 12:48 PM
Jens, I think what you describe is a real problem. I tend to think of this as programmer personality types. This isn’t new, but I like to break these personality types into three basic forms: wild eyed dreamer, get on the bus, and get this puppy out the door. There are other types (one of my favs is the I just want hard debugging problems to solve) but these are the ones I think companies need to be aware of… You need the wild eyed dreamers to come up with the cool next gen ideas and to get the up to proof of concept stage (or just past). You need the get on the bus types to take the wild eyed dreamers work and make it a commercial product. The get this puppy out the door type is the finisher of the bunch… Problem is, who does the hiring? Most companies/teams hire in their own image. That means many teams/companies are top heavy with one of the three personalities… Guess what that means to the bottom line…
I could go in, as I’ve experienced this problem repeatedly in my career. But I won’t.
Donald
October 23rd, 2007 at 9:31 AM
It is true - programmers need that mental model, and the problem is that six months from now, you’ve forgotten it and your code looks like it was written by somebody else. I think what’s far more important than the code alone is that mental model - so the path forward in software development is to somehow capture or represent it. In a large, complex, evolving software system, much of what we are doing is not code - its bugs and schedules and documentation and stuff - is actually done with computer tools already. Code doesn’t exist in isolation and the fact that this bit of code has a known but or is slow is important and can easily be represented in such a system. When you’re looking at a specific portion of code, for instance, it should be clear that there is a known bug. Or the fact that it is slow, or has had some discussion threads about it. I’m sure we can connect all this stuff up in a way that creates a larger context for much of the little independent pieces. while it can never be a substitute for understanding a system, I think it would help create that mental model a whole lot faster.
February 24th, 2008 at 2:36 PM
Maybe I’m getting this all wrong, but I’ve always liked the idea of sketching about programming. That, just as a musician working on a piece, perfecting it with every pass, programs are never “completely in your head”, but rather it’s a series of actions that then lead to the full thing.
IIRC, it was Paul Graham himself who articulated this idea in Hackers & Painters and this particular statement seems to contradict it. :/
February 24th, 2008 at 3:46 PM
filipp — I agree about programming being like sketching, a process of incremental refinement. But the difference is that the sketch is much bigger than you can see at once, so you have to have a good mental model of it as a whole.