Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Holding a Program in One's Head (2007)

paulgraham.com

Post reply on HN
Print view View original

81–90 of 114 posts

Re: Holding a Program in One's Head (2007)

#81

Post by noufalibrahim »

I don't know how far this can go but it's a feeling that I've had which is relevant and some people might resonate with.

I used some tiny devices (e.g. Casio PB80 http://oldcomputermuseum.com/casio_pb80.html) as a kid to write small programs on in BASIC. It has only a single line of display and you had to sort of remember where things were to make your GOTOs work properly etc. This means that most of the program had to be in your head. You couldn't easily jump between things and see the whole thing as a single screen of text. I also remember reading that people like Ken Thompson wrote significant parts of the original UNIX on a line editor (ed). That would also mean that most of it had to be in his head in a semi parsed format.

Sure, with modern editors and IDEs, you can outsource that to the computer and focus on the more valuable stuff but I still wonder how much the grunt work of remembering things in detail is under appreciated in creative work.

Re: Holding a Program in One's Head (2007)

#82

Post by jpc0 »

xanderlewis wrote: post #36
nickdrozd wrote: post #2

> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…

The comparison with mathematics also makes sense here. It’s much easier to spot typos in other peoples’ work than your own for exactly that reason: when you read back what you wrote, you read back what you meant to write rather than what’s actually there. Open any textbook (even a fourth edition of a famous one, written by an expert) and you’ll find countless typos. In fact, in a certain sense, the more expert you ar…

You touched on it but I've experienced the same reading code when I knew what was intended by the code, regardless of who wrote it. I miss obvious but simple bugs because I only read what it is mean to do.

Re: Holding a Program in One's Head (2007)

#83

Post by jpc0 »

4star3star wrote: post #32
nfw2 wrote: post #24

Earlier quoted context omitted.

I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…

I think DRY should be supplemented by "Don't make me read it multiple times". Repeat yourself, by all means, if that makes it so that I don't get all twisted up jumping between so many files that I can't keep the main thread straight while I read your code.

Another on this. If you abstract away code that throws or returns an error document that somehow.

The amount of times I've had to dig through 6 levels of abstraction to find what error gets returned in some edge case so I can catch and handle it gave me PTSD and gave me not invented here syndrome.

Re: Holding a Program in One's Head (2007)

#84

Post by Aeglaecia »

minkles wrote: post #54
Aeglaecia wrote: post #50

Earlier quoted context omitted.

imagine having the brain to synthesise every function across a codebase , most humans gotta settle for interfaces :p

Interfaces are just collections of function prototypes.

and some projects have more interfaces than are memorable by the average human

Re: Holding a Program in One's Head (2007)

#85

Post by zubairq »

Brilliant article. I read a brilliant book written by Jessica Livingston (Paul Graham's wife) called Founders at Work. In the book Steve Wozniak talked about how he got designs done fast by keeping it all in his head. Ever since I read that I have tried to do the same. I would recommend this to anyone working on their own project.

Of course in a corporate setting it is much harder to do as you have code written in multiple languages using multiple patterns stored in different places, so often there is not underlying architectural thread to hold it all together.

Re: Holding a Program in One's Head (2007)

#86

Post by minkles »

jll29 wrote: post #78
minkles wrote: post #42

Earlier quoted context omitted.

Those are called functions.

The UNIX way would be to break things down into actual programs, where each one would be doing one thing well - and in such a way that they'd be useful as building blocks for solving other problems also.

The unix way is re-parsing text 5000 times in separate programmes with no consistency or contract between them really.

That's not great.

Re: Holding a Program in One's Head (2007)

#87

Post by xanderlewis »

lanstin wrote: post #57
xanderlewis wrote: post #36

Earlier quoted context omitted.

The comparison with mathematics also makes sense here. It’s much easier to spot typos in other peoples’ work than your own for exactly that reason: when you read back what you wrote, you read back what you meant to write rather than what’s actually there. Open any textbook (even a fourth edition of a famous one, written by an expert) and you’ll find countless typos. In fact, in a certain sense, the more expert you ar…

One of my undergrad tutors taught complex analysis with a book she had written, and she offered a reward for any one who found an error. She said the best students never claimed the reward, only the people that had to study each word carefully.

I proudly study each word carefully.

Re: Holding a Program in One's Head (2007)

#88

Post by HumblyTossed »

nickdrozd wrote: post #2

> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…

I don’t think that quote is true in all situations. I have worked with a couple developers long enough their code reads to me as easy as my own.

Re: Holding a Program in One's Head (2007)

#89

Post by ahoka »

HumblyTossed wrote: post #88
nickdrozd wrote: post #2

> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…

I don’t think that quote is true in all situations. I have worked with a couple developers long enough their code reads to me as easy as my own.

Sometimes when I do code reviews, I understand other's code better than they do and find bugs they don't see. So yeah.

Re: Holding a Program in One's Head (2007)

#90

Post by mejutoco »

jimbokun wrote: post #41

A good way to keep a program in your head: Break it up into a few or several smaller programs that interact through clean interfaces. Then you can keep one smaller, simpler program in your head at a time, then integrate them at the end once all the smaller programs are working.

Making as much of the program as possible pure functions and enforcing types works extremely well for this task. I would only add clean _enforced_ interfaces are key.
Post reply on HN