Holding a Program in One's Head (2007)
paulgraham.com
Holding a Program in One's Head (2007)
1–10 of 104 posts
Re: Holding a Program in One's Head (2007)
#2Rings true...
I definitely work best in 4-10 hour focused sessions, can easily do a weeks worth of work in one go. I can't always make those sessions happen though. Coding block? I guess I should write. [1] :)
Around the time this was written, I was working somewhere you had to break all the rules to get anything accomplished. The un-sanctioned stuff was of much higher quality and function.
[1] http://tommy.authpad.com/understanding-and-combatting-coder-...
Re: Holding a Program in One's Head (2007)
#3Not sure about working for long uninterrupted sessions(I tend to believe that short, self-scheduled breaks increase my productivity, as per the pomodoro technique), but I think the notion of loading a 'context' into your memory is spot-on. I know that, at least for me, it is difficult to even begin working on a problem unless I have that initial context in my head; without a full understanding of the problem at hand, I feel like I can't do anything well.
Re: Holding a Program in One's Head (2007)
#4Wow, this is particularly true when you're not rapid prototyping. An aha moment happens when one is able to reverse think a complete chain of events leading up to a catastrophic failure because you saw a tiny UI/UX bug on the surface.
Paul has written such splendid pieces that should resurface from time to time. This thread has happened [1] to YC community before.
Re: Holding a Program in One's Head (2007)
#5This is very similar to how a lot of writers that do split point-of-view write their stories. "Load" all the information needed for a particular point-of-view, write all of theirs chapters, unload, and repeat.
Re: Holding a Program in One's Head (2007)
#6I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering.
I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it.
(Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)
Re: Holding a Program in One's Head (2007)
#7I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)
We have - it's called an API. The way to work on big programs, too big to hold in your head all at once, is to break them into a bunch of little programs, each of which does something you can hide behind a simple interface. Then you hold all of the library in your head at once, and possibly repeat the same process.
The complexity comes in that this really does just approximate holding the whole program in your head, and sometimes you find the API is not adequate to what you want to do. Then you're back to square one, except with a codebase that by definition is too big to hold in your head.
Re: Holding a Program in One's Head (2007)
#8In my experience, this is PG's most helpful/ reassuring technical essay.
Recently I was working on/ creating pretty complex algorithms with gargantuan cobweb of edge cases. Not only did I had to work for 15+ straight hours, but in order to maintain productivity fasted (bar caffeine, few nuts & water) every alternate day to keep the steam going.
Incredible times, and rather close to reaping the fruits now, but there is a pretty good chance that I would not have been here had I not read and internalized this essay- was grappling with several decades of CS research though in much less theoretical setting.
Re: Holding a Program in One's Head (2007)
#9One good test for this is if you can explain in abstract terms, and preferably to a non programmer, how the program works.
Re: Holding a Program in One's Head (2007)
#10It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance.
pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp for that very reason, but Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.