Meta information

• Speaker: Joran Dirk Greef
• URL: https://www.youtube.com/watch?v=w3WYdYyjek4

Executive Summary

I'll write the executive summary – my takeaways from the talk – when I see the talk a second (or maybe third) time. Nothing to add for the moment.

Notes on the video

• (Pg 4:59) "Tigerstyle sees the whole picture, checks yourself before you wreck yourself, gives you a time-machine!"
• (Pg 6:25) "Decide your tools on quality, not quantity" [tools]
• (Pg 7:25) "Developing a system is not just about coding … the design phase before and after, the coding, the testing phase after coding and the operator experience in production" [coding]
• (Pg 7:55) "Total time of ownership = Design + Coding + Testing + Incidents" [shipping]
• (Pg 10:10) "An hour in design is worth weeks in production" [quotes]
  • by Joran Dirk Greef
• (Pg 10:40) "Simple and Elegant Systems tend to be easier and faster to design and get right, more efficient in execution and much more reliable" [quotes]
  • by Edsger Dijkstra
• (Pg 13:10) "Testing is what dominates the development of complex systems." [testing]
• (Pg 13:15) "Callout to Jepsen as a great tool for testing distributed systems!" [jepsen, clojure]
• (Pg 15:25) "There is more to software than just engineering" [building]
• (Pg 18:40) "Four colors of systems programming: Network, Disk, Memory, CPU" [distributedsystems]
• (Pg 18:56) "The two textures that all these colors share are: latency and bandwidth" [distributedsystems]
• (Pg 19:10) "In the design phase … 1) Back of the envelope calculations" [design]
• (Pg 19:30) "Sketch as many solutions as you can using … (colors, textures) .. because sketches are cheap and rewrites are expensive" [design]
• (Pg 19:40) "Find great names for your components … TigerStyle doc in our repo gives you tips on naming" [design]
• (Pg 20:35) "Define your mechanical fault models" [design]
  • Think through your fault models and see if your system is designed accordingly.
• (Pg 21:10) "Be explicit up front about the fault models your system can tolerate" [design]
• (Pg 21:40) "Stateless is always better than stateful" [design,state]
  • State is very hard! :D
• (Pg 22:00) "It pays to reduce surface area that you commit to." [design]
• (Pg 23:00) "Zero Technical Debt policy … do the best that you currently can … do it right the first time" [design]
  • Knowing that your work is solid motivates your team
• (Pg 26:30) "Assertions: NASA's power of ten rules for safety critical code" [reference]
  • Your system should run safely or not at all .. shut down in the face of a bug.
• (Pg 27:30) "Write assertions checking your function arguments" [correctness]
  • that they are as you expect, and also assert that they are correct in relation to each other.
  • and you do the same for the return value
  • now your functions are contributing to correctness
• (Pg 27:42) "The ultimate purpose of abstraction is for correctness" [quotes]
  • By Joran
• (Pg 29:00) "If it compiles, you've just begun!" [correctness]
• (Pg 30:20) "Start to think like a hacker: what don't you expect? What would be unusual in this case?" [hackers]
• (Pg 32:40) "Everything has a limit … systems have limits .. make them explicit so that your design can handle edge-cases" [limits, distributedsystems]
• (Pg 36:10) "Assertions are a force-multiplier for testing" [testing]
  • Do not let your programming language turn them off in production!
• (Pg 45:50) "Assertions document invariants" [testing]
• (Pg 47:30) "(our fuzzy simulator) .. push the faults to the very theoretical limit .. at rapid time" [fuzzying, testing, distributedsystems]

Published On: Mon, 26 Jun 2023. Last Updated On: Tue, 14 May 2024.