Holding a Program in One's Head (2007)
paulgraham.com
Holding a Program in One's Head (2007)
1–10 of 114 posts
Re: Holding a Program in One's Head (2007)
#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 really going on, since you just see what's there.
Re: Holding a Program in One's Head (2007)
#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 parts being distributed everywhere! That’s what you’d also call a “leaky abstraction”
Re: Holding a Program in One's Head (2007)
#4> 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, for instance, learned years ago to refuse to help people debug promise chains in languages with async-await semantics. Rewrite it and then get back to me if it still doesn’t work. They usually transcribe the intent of the chain and not the letter of it, fixing the bug they can’t see. And if not the error makes enough sense they can figure it out.
Re: Holding a Program in One's Head (2007)
#5I 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.
Re: Holding a Program in One's Head (2007)
#6I 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.
A quote originally (AFAIK) from the wonderful book 'Practical Common Lisp'.
Re: Holding a Program in One's Head (2007)
#7Re: Holding a Program in One's Head (2007)
#8> […] 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 is what I believe as well. Also throw in some Functional Programming (isolating pure functions and side-effecting functions) for extra benefits.
Re: Holding a Program in One's Head (2007)
#9> 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.
Re: Holding a Program in One's Head (2007)
#10> […] 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 is what I believe as well. Also throw in some Functional Programming (isolating pure functions and side-effecting functions) for extra benefits.
Both excellent points, and I would add a recommendation for high level organization: to consider the data then the process. If you can draw a graph where every data structure is only connected to a process, and vice versa, and that processes may take multiple inputs but only produce a single output type, it will make holding the entire system in your head a lot easier, even for very scaled-up systems.
Bonus points if you can distinguish between essential state and circumstantial state.