We should do (as wise programmers aware of our limitations) our utmost best to … make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
To solve problems at scale, paradoxically, you have to know the smallest details. Jeff and Sanjay understood computers at the level of bits. Jeff once circulated a list of “Latency Numbers Every Programmer Should Know.” These numbers are hard-wired into Jeff’s and Sanjay’s brains. As they helped spearheaded several rewritings of Google’s core software, the system’s capacity scaled by orders of magnitude.
In terms of sexiness, compilers are pretty much as boring as it gets. On the other hand, they get you very close to the machine. Jeff has a model going on as you’re writing code. What is the performance of this code going to be? He’ll think about all the corner cases almost semi-automatically.
He is known for being quiet but profound — someone who thinks deeply and with unusual clarity. On his desks, he keeps a stack of Mead composition notebooks going back nearly 20 years, filled with tidy lists and diagrams. He writes in pen an in cursive. He rarely references an old notebook, but writes in order to think. At MIT, his graduate adviser was Barbara Liskov, an influential computer scientist who studied, among other things, the management of complex code bases. In her view, the best code is like a good piece of writing. It needs a carefully realized structure; every word should do work. Programming this way requires empathy with readers. It also means seeing code not just as a means to an end but as an artifact in itself.
Jeff’s programming is dazzling — he can quickly outline startling ideas — but, because it’s done quickly, in a spirit of discovery, it can leave readers behind. Sanjay’s code is social.
“Some people, their code’s too loose. One screen of code has very little information on it. You’re always scrolling back and forth to figure out what’s going on. Others write code that’s too dense. You look at it, you’re, like, ‘Ugh. I’m not looking forward to reading this.’ Sanjay has somehow split the middle. You look at his code and you’re like, ‘OK, I can figure this out.’ Whenever I want to add new functionality to Sanjay’s code, it seems like the hooks are already there. I feel like Salieri. I understand the greatness. I don’t understand how it’s done.”
Software architecture is about making fundamental structural choices that are costly to change once implemented.
A set of architectural design decisions: software architecture should not be considered merely a set of models or structures, but it should include the decisions that lead to these particular structures, and the rationale behind them.