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

21–30 of 114 posts

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

#21

Post by dkarl »

mingusrude wrote: post #5

I once watched a presentation by Dan North where he said that a microservice should never be bigger than your head. What he meant was that all the code for the microservice should fit on your screen and you should be able to put your head against the screen and it should cover the code. Yes, this was in the microservices-heyday.

Anything you create in software should be able to fit in someone else's head. I.e., you should be able to think of it as a tractable arrangement of abstractions that let you reason about it in a precise, non-leaky way.

Those abstractions don't just poof into existence after the project is complete, though. You have to design them into the system and communicate them to the people who need them.

The abstractions also need to be precise and non-leaky enough to be useful. One of the most dangerous talents in software is the ability to create the illusion of tractability by using vague language. You can create an absolute mess and then describe it to management in a way that makes it sound well-understood. This is the most lucrative and destructive skill a consultant can have.

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

#22

Post by zimpenfish »

WillAdams wrote: post #16
corytheboyd wrote: post #3

> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…

This seems to be one of the core lessons behind John Ousterhout's _A Philosophy of Software Design_ https://www.goodreads.com/book/show/39996759-a-philosophy-of... and I find that the mechanism of "Literate Programming": https://literateprogramming.com/ is a useful one for doing this since it allows one to write about both how the low level details are implements in a function, _and_ how the written function is used…

That needs to be http://literateprogramming.com/ at the moment because their certificate / HTTPS setup is borked.

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

#23

Post by akira2501 »

rshudson wrote: post #18

Take a look at the list of people who read the draft of this post. > Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this.

People who are famous for running companies and not writing code.

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

#24

Post by nfw2 »

corytheboyd wrote: post #3

> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…

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

I hope the various theories behind what constitutes good code will make their way out of scattered blog posts and into CSE curriculum.

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

#25

Post by nfw2 »

saghm wrote: post #9
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 often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.

This is one of the reasons I think that the push towards server-side UI is misguided. It's much easier to walk through the runtime of a program running locally than it is to step through a render that's distributed across a network.

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

#26

Post by alphazard »

saghm wrote: post #9
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 often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.

> wouldn't be a bug if everything was happening exactly according to expectations

This isn't quite true, especially concerning distributed systems. It's relatively common for a software system to be broken by design. It's not that the developer didn't know how to use the programming language to get the computer to do what they want. It's that what the developer wanted reflects a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users.

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

#27

Post by saghm »

alphazard wrote: post #26
saghm wrote: post #9

Earlier quoted context omitted.

I often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.

> wouldn't be a bug if everything was happening exactly according to expectations This isn't quite true, especially concerning distributed systems. It's relatively common for a software system to be broken by design . It's not that the developer didn't know how to use the programming language to get the computer to do what they want. It's that what the developer wanted reflects a poor model of the world, a logical in…

Keep in mind I said that this is advice I give junior engineers specifically; they shouldn't be the ones responsible for designing distributed systems in the first place. For someone in that part of their career, this advice is meant to help to learn the skills the need to solve the problems they're dealing with, and it's not intended to be universal to all circumstances, just a useful thing to keep i mind.

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

#28

Post by monocasa »

alphazard wrote: post #26
saghm wrote: post #9

Earlier quoted context omitted.

I often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.

> wouldn't be a bug if everything was happening exactly according to expectations This isn't quite true, especially concerning distributed systems. It's relatively common for a software system to be broken by design . It's not that the developer didn't know how to use the programming language to get the computer to do what they want. It's that what the developer wanted reflects a poor model of the world, a logical in…

That sounds distinctly like an expectation that didn't hold.

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

#30

Post by norir »

I more or less agree with the main thesis although I would point out that typical software development practices in industry make this very difficult. Fred Brooks told us to plan to throw out the first draft. Industry says ship it.
Post reply on HN