5 ms·

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design softw

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design software, but also ways to live. [redacted]’s work is also directly influenced by [redacted], as referenced at the end of his article. For [redacted], I suggest looking at the class website: [redacted] For [redacted], I suggest his book, [redacted]

simplegeek 3y ago
> He taught not just ways to design software, but also ways to live. Mind sharing his insights on ways to live?
- v9v 3y ago
  Not parent commenter, but I recall seeing this talk of his posted online before: https://gist.github.com/gtallen1187/27a585fcf36d6e657db2 https://gist.github.com/gtallen1187/27a585fcf36d6e657db2
codeflo 3y ago
I'm a fan of Ousterhout's writing; "A philosophy of software design" clarified a lot of my thinking around complexity. I find the "Grug Brain" stuff pretentious and dishonest. "Me not smart. Me like simple things. Me not believe in hype. Hence why me invent complex new frontend framework, and then me hype it up beyond reason." (To be clear what I'm saying, my point is not that HTMX is overhyped -- it might be, but then so is everything. It's specifically the hypocrisy of the "we're against hypes" hype that makes me cringe.)
- cryptography 3y ago
  Do you think this would be beneficial for a somewhat perplexed CTO of a newly seed-funded startup? Or would it be wiser for me to concentrate on my current responsibilities and return to this book when my mind is clearer? I'm feeling a bit overwhelmed and under pressure, and I'm concerned that reading this book might add to the chaos. I would appreciate your input.
  - deleted 3y ago
    [deleted]
  - LewisJEllis 3y ago
    APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less. It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.
- resonious 3y ago
  I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with.
  - TeMPOraL 3y ago
    Grug has some good points about complexity, but proceeds to take it all the way to full-blown, self-defeating anti-intellectual and anti-professional attitude. It makes sense for imaginary cavemen, but not for practitioners of a profession - people both capable and expected to learn the tools of their craft and continue learning past their first job interview.
    - recursivedoubts 3y ago
      ironically, i teach at a university agree that anti-intellectualism is a danger if you take grugbrainism too far
exclipy 3y ago
Rich Hickey is the odd one out. What do you see in someone who shuns static typing? Static typing is the clearest way to reduce complexity.
- synthc 3y ago
  static typing is a way to manage complexity, Rich Hickey is about avoiding complexity
  - hu3 3y ago
    But there's no way to completely avoid complexity. So tools to manage complexity are welcome in my toolbox.
    - nlitened 3y ago
      Tools have their defined use cases. If you use the same tool in all cases, you’re probably misusing it.
tabtab 3y ago
Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers. Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.) I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps. I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.

simplegeek 3y ago

> He taught not just ways to design software, but also ways to live. Mind sharing his insights on ways to live?

v9v 3y ago
Not parent commenter, but I recall seeing this talk of his posted online before: https://gist.github.com/gtallen1187/27a585fcf36d6e657db2 https://gist.github.com/gtallen1187/27a585fcf36d6e657db2

codeflo 3y ago

I'm a fan of Ousterhout's writing; "A philosophy of software design" clarified a lot of my thinking around complexity. I find the "Grug Brain" stuff pretentious and dishonest. "Me not smart. Me like simple things. Me not believe in hype. Hence why me invent complex new frontend framework, and then me hype it up beyond reason." (To be clear what I'm saying, my point is not that HTMX is overhyped -- it might be, but then so is everything. It's specifically the hypocrisy of the "we're against hypes" hype that makes me cringe.)

cryptography 3y ago
Do you think this would be beneficial for a somewhat perplexed CTO of a newly seed-funded startup? Or would it be wiser for me to concentrate on my current responsibilities and return to this book when my mind is clearer? I'm feeling a bit overwhelmed and under pressure, and I'm concerned that reading this book might add to the chaos. I would appreciate your input.
- deleted 3y ago
  [deleted]
- LewisJEllis 3y ago
  APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less. It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.
resonious 3y ago
I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with.
- TeMPOraL 3y ago
  Grug has some good points about complexity, but proceeds to take it all the way to full-blown, self-defeating anti-intellectual and anti-professional attitude. It makes sense for imaginary cavemen, but not for practitioners of a profession - people both capable and expected to learn the tools of their craft and continue learning past their first job interview.
  - recursivedoubts 3y ago
    ironically, i teach at a university agree that anti-intellectualism is a danger if you take grugbrainism too far

exclipy 3y ago

Rich Hickey is the odd one out. What do you see in someone who shuns static typing? Static typing is the clearest way to reduce complexity.

synthc 3y ago
static typing is a way to manage complexity, Rich Hickey is about avoiding complexity
- hu3 3y ago
  But there's no way to completely avoid complexity. So tools to manage complexity are welcome in my toolbox.
  - nlitened 3y ago
    Tools have their defined use cases. If you use the same tool in all cases, you’re probably misusing it.

tabtab 3y ago

Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers. Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.) I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps. I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.