4 ms·

I don't know if the book goes into this, but one thing I've noticed about brilliant software people like Jeff Dean or Martin Thompson is that they appear to lov

I don't know if the book goes into this, but one thing I've noticed about brilliant software people like Jeff Dean or Martin Thompson is that they appear to love doing simple "back-of-the-envelope calculations" (and lots of them). They can iterate designs rapidly in their head or on paper, evaluate the cost or value of a design, know when a design has promise or when it won't work, and where the bottlenecks or low-hanging fruit might be, because they have a good feel for the performance/scaling cost of all the resources involved along the axes of things like branch mispredicts, main memory references, per core memory bandwidth, disk seeks, disk bandwidth, network latency, network bandwidth, expensive memory vs inexpensive storage tradeoffs. Numbers that programmers should know [1] but often don't. In other words, before they even write specifications or start coding, they've probably done tens to hundreds of back-of-the-envelope calculations to put their design in the "roughly right" ballpark. This drastically increase the chances that the design is going to work, and work really really well. And I think this habit is also what tends to set them apart. [1] https://colin-scott.github.io/personal_website/research/interactive_latency.html https://colin-scott.github.io/personal_website/research/inte...

cinntaile 5y ago
There's a monthly newsletter dedicated to napkin math. He hasn't made one in a few months for some reason, but judging from his tweets he's working on a new one. You can also practice on the old ones of course. https://sirupsen.com/napkin/ https://sirupsen.com/napkin/
- read_if_gay_ 5y ago
  Also a nice guest lecture by Kernighan at Harvard: https://youtu.be/kw9KwjJCJH8 https://youtu.be/kw9KwjJCJH8
bob1029 5y ago
One other very similar path is to start with domain modeling. Figure out what all of the facts, types and relations are in abstract terms before you write a single line of code. Excel is exceedingly capable at this type of design work. I see abstract domain modeling combined with practical engineering constraint solving as the foundations of the discipline. Being able to simultaneously operate in abstract academic terms (e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done.
- mbil 5y ago
  Can you talk more about using Excel for this type of design work? Sounds interesting, but I’m not exactly sure what you mean.
  - bob1029 5y ago
    One worksheet per table you think you would want to create in an ideal SQL database representing the business domain. For instance: Worksheet #1: Customers ColA: Id ColB: Name ColC: Email ... Worksheet #2: Orders ColA: Id ColB: CustomerId ColC: ItemId ColD: OrderDateUtc ... You probably want to fill in a few example rows per table to illustrate intent and how things relate together. The advantages with this approach are impossible to overstate. Being able to send a dead-simple spreadsheet via email to your domain experts can save a ton of frustration and meetings.
    - Jtsummers 5y ago
      You can also implement rudimentary logic strictly with Excel functions, no need for VB, to create a kind of MVP/prototype of the system. Then it can be migrated to a real database or other representation format and program once you have a solid idea of what you're representing and why. And since it's data-centric there's less of a tendency to screw up by mixing the data layer and logic layer too much within this prototype, you're almost forced to create a clean separation. Then you have a data model that you can use in the core of a variety of applications with various business and view logics distinct or common between each.
- jorangreef 5y ago
  "(e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done." I wouldn't put abstract domain modeling or database normalization alongside a first principles back-of-the-envelope approach. Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the first principles things, the physical facts, like cache lines and latency ("practical engineering constraint solving" as you put it well) that drive the best designs, and far ahead of things like database normalization. This is also the approach taken by Data-oriented Design [1], which is more similar I think, than the abstract domain modeling approach. In fact, abstractions and domain modeling principles can often lead one away from the ground reality of the machine, or "mechanical sympathy". [1] https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design

cinntaile 5y ago

There's a monthly newsletter dedicated to napkin math. He hasn't made one in a few months for some reason, but judging from his tweets he's working on a new one. You can also practice on the old ones of course. https://sirupsen.com/napkin/ https://sirupsen.com/napkin/

read_if_gay_ 5y ago
Also a nice guest lecture by Kernighan at Harvard: https://youtu.be/kw9KwjJCJH8 https://youtu.be/kw9KwjJCJH8

bob1029 5y ago

One other very similar path is to start with domain modeling. Figure out what all of the facts, types and relations are in abstract terms before you write a single line of code. Excel is exceedingly capable at this type of design work. I see abstract domain modeling combined with practical engineering constraint solving as the foundations of the discipline. Being able to simultaneously operate in abstract academic terms (e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done.

mbil 5y ago
Can you talk more about using Excel for this type of design work? Sounds interesting, but I’m not exactly sure what you mean.
- bob1029 5y ago
  One worksheet per table you think you would want to create in an ideal SQL database representing the business domain. For instance: Worksheet #1: Customers ColA: Id ColB: Name ColC: Email ... Worksheet #2: Orders ColA: Id ColB: CustomerId ColC: ItemId ColD: OrderDateUtc ... You probably want to fill in a few example rows per table to illustrate intent and how things relate together. The advantages with this approach are impossible to overstate. Being able to send a dead-simple spreadsheet via email to your domain experts can save a ton of frustration and meetings.
  - Jtsummers 5y ago
    You can also implement rudimentary logic strictly with Excel functions, no need for VB, to create a kind of MVP/prototype of the system. Then it can be migrated to a real database or other representation format and program once you have a solid idea of what you're representing and why. And since it's data-centric there's less of a tendency to screw up by mixing the data layer and logic layer too much within this prototype, you're almost forced to create a clean separation. Then you have a data model that you can use in the core of a variety of applications with various business and view logics distinct or common between each.
jorangreef 5y ago
"(e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done." I wouldn't put abstract domain modeling or database normalization alongside a first principles back-of-the-envelope approach. Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the first principles things, the physical facts, like cache lines and latency ("practical engineering constraint solving" as you put it well) that drive the best designs, and far ahead of things like database normalization. This is also the approach taken by Data-oriented Design [1], which is more similar I think, than the abstract domain modeling approach. In fact, abstractions and domain modeling principles can often lead one away from the ground reality of the machine, or "mechanical sympathy". [1] https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design