elehack.net

Holding a Program in One's Head

Paul Graham wrote an interesting article about the art of programming, particularly of holding a program in one’s head. He has a number of points worth contemplation, even if he isn’t spot-on in everything.

I find it interesting how well he describes how I operate. Reflecting on my time at the SCL, his descriptions parallel the types of things that let me keep going. I really did have Goanna in my head. I rewrote portions of it a lot. Several times, I was questioning whether my modus operandi was really in my supervisor’s best interest; there does come a point, I believe, that excessive rewriting, etc. is not a profitable use of time. But Graham does accurately describe how my mind was functioning. The times I was able to get the program fully loaded into my head, I was able to work for an extended period and accomplish good work. If I unloaded the program, or even unloaded a task, my work was difficult.

So now the mission before me seems to be this: critically evaluate what Graham has said. Some of the characteristics that he describes are useful disciplines, and I should endeavor to cultivate them. Avoiding distractions comes to mind — if I need to work for a while on some code, I need to train myself to find a place and time where I can be undisturbed in my labors. Some of his points are just plain facts, and I need to learn to deal with them properly. The fact that it takes time to load a program into one’s head, for example. There is a limit as to what one can do to reduce this overhead, so I need to identify when the load time of a project will be an issue and structure my work on that project in such a way as to reduce the negative effects and perhaps harness the loading/unloading action to my benefit.

Some things should be taken with a grain of salt. His comments on one-person-per-piece-of-code, for example. I’ll have to side with The Third Bit on this one. It is good for multiple people to be able to understand a piece of code. It may be a fact that this is difficult, but that merely means that developers should work to overcome this difficulty rather than accept it and overly segregate work. My opinions on this may change as I gain more experience with groups, but it seems reasonable that expecting that no one else will need to work with your code is a recipe for disaster.

Comments

No comments posted.

Post a Comment

You may post a comment using the form below. All fields are optional. By submitting a comment, you release it to Michael and Jennifer Ekstrand under the Creative Commons Attribution 3.0 license. See our copyright notice for details. You might also want to read our privacy statement.