33 thoughts on “John Ousterhout: “A Philosophy of Software Design” | Talks at Google

  1. More things to think about:
    1. Every line should do one and only one thing. Nested methods/functions are typically harder to read and debug. "One line of code" is the enemy if it hides multiple branches of logic, aside from the standard one-line if-else statements. These should either be broken out for readability, or refactored to better handle the parameters available.
    2. Teach some basic ideas for reducing cyclomatic complexity… shorter methods/functions, eliminating if-else-statments (and particularly else-statements), etc.
    3. Use good tools that point out errors in your code automatically, like Jetbrains products or the various Linting tools. Also use more modern/advanced IDEs. The downside is that each tool comes with a learning curve (and some cost $$$).

  2. I'm genuinely surprised this is the state of programming in 2018. I'm also disappointed that in an hour long discussion on software design not a single mention of writing secure code. Every programmer has to put on their black hat and think about how an adversary might take advantage of poorly designed code (buffer overflows, deliberate crashing, input validation, etc).

  3. The book is well worth it. Thanks Prof Ousterhout.

    Edit: and I would add that it shines most at providing the rationales behind certain "good practices" which are more used as dogma than as heuristics to produce strong systems. Some of these rationales are not trivial (at least not for me!) and understanding them will shape your intuition for future work. Nicely done.

  4. Slides for an earlier version of the talk: https://platformlab.stanford.edu/Seminar%20Talks/retreat-2017/John%20Ousterhout.pdf

  5. When he posed the first question I immediately thought: divide and conquer, seems pretty close( to "problem decomposition")

  6. I think the paper mentionned at 12:40 is https://web.archive.org/web/20180108050207/http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf (not available (403) anymore on the cs.umd.edu website).

  7. i like the idea of getting some basic rules and agreements for software design . i think only this way progress can be made

  8. You can have the public function do the deep thing with less than 20 lines of code, just separate the levels of abstraction into different functions. code in function must not cross levels of abstraction

  9. Nothing here is new or anything more than simple age-old common sense, "measure twice, cut once", be disciplined. "Don't overuse exceptions" wow incredible insight, 40 year's of wisdom….. "hard to know if the course is working" LOL, what a joke, 1000 lemmings thumbs up.

  10. This video is mostly a waste of time but illustrates how SW programmers think they're smarter than they actually are. perfect example is the word-salad nonsense question at 52:20 that is pretty much incoherent and John dodges it for that very reason

  11. I wish there might be an open access to his software design studio class for public.

    I'm really curious about how they teach the student about tackling design problems.

Leave a Reply

Your email address will not be published. Required fields are marked *