[dead]
Holding a Program in One's Head (2007)
51–60 of 114 posts
Re: Holding a Program in One's Head (2007)
#52Take 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.
I’m always amazed at the impressive list of people pg gets to review his essays. His recent essay “Founder mode” was no exception.
Re: Holding a Program in One's Head (2007)
#53I 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.
That is true. Then these drafts travel, fly, and feed you. Don’t be surprised by plastic in every micron of space — it was just a draft. By the way, the first refrigerators without Freon also caused harm, but back then people were only thinking about reliability and didn’t have the resources to tackle the full scope of the problems. Now the goals have changed driven by the pursuit of profit
Re: Holding a Program in One's Head (2007)
#54Re: Holding a Program in One's Head (2007)
#55Earlier quoted context omitted.
> 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.
"a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users"
I expect when I pull from the queue (but it was designed non-atomically) that I will be guaranteed to only grab the item once and only once, even after a failure. That expectation is wrong, but the developer may have implemented their intent perfectly, they just didn't understand that there are error cases they didn't account for.
Re: Holding a Program in One's Head (2007)
#56Earlier quoted context omitted.
That’s why I learned to log literally everything into stdout unless a process is time-sensitive and it’s deep production and it passed the mark where bugs and insights occur once a month+ and there’s zero chance someone asking me what exactly happenes with X at Y afternoon-ish last Friday. The obvious exception are recursive number-fiddling algos which would spam gigabytes of output due to big N. This way I can just…
For large systems the cost of maintaining all of those logs in a searchable system can be prohibitive.
Just reduce the time horizon you keep the logs until you can afford it. Also, as he mentioned, once a system is getting bugs infrequently, you can lower the log level. My standard is to have a log msg for each branch in the code. In C, I would use macros to also have a count of all the fmt strings the log package encountered (so I still got a sort of profile of the logic flows encountered, but not have the sprintf expense), but I haven't figured out an efficient way to do that in Go yet (i.e. not using introspection).
Re: Holding a Program in One's Head (2007)
#57> 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…
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.
Re: Holding a Program in One's Head (2007)
#58> 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…
There's some idiom that says something like "you don't understand something if you can't explain it." I think this is the real point of code review. To make a case for why your code is valuable. If it's just a blob of 1000 lines of "refactor" or "adding feature." It means nothing. A good commit has some kind of abstract tailored to what work was done. Then a review becomes something like "the claim was made this func…
There is a balance there. You can have 1000 trivial commits making it hard to see the fact you just have 10 features, and ten mind-breaking commits making it hard to see what each feature entails. (Then there's the 50 commits "try this" where you are fighting CI or CD and can't test without going thru a git commit/push.)
Re: Holding a Program in One's Head (2007)
#59A 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.
Those are called functions.
Sometimes.
Sometimes it is one or more programs writing to a queue or topic, and other programs reading from that topic.
Or programs writing to and others reading from a Unix pipe.
Or programs talking to each other using HTTP.
Or Erlang processes communicating concurrently on one machine or across a network.
Or different programs sharing one database.
Or many objects communicating by passing messages in a small talk program.
There are many ways to encapsulate programs and have them interact.
Re: Holding a Program in One's Head (2007)
#60I'd add "Focus on the Nouns, not the Verbs", or more prosaically, the data and the changes that occur to data, not the process of changing it.