Stuart Halloway - Narcissistic Design
Reaktor4 HN recommenders · 2018–2021
29K views · talk · evergreen · Uploaded 2017-02-20
Stuart Halloway's satirical talk describes how to protect yourself from industry change by spreading complexity through systems while following idiomatic practice. It uses this inversion to catalog software design anti-patterns.
HN commenters love it as a witty and insightful tour of design anti-patterns, applicable to DSLs, OOP and API design.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
42:03The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:31:06William Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
1:00:19How To Design A Good API and Why it Matters
Google TechTalks
31:44The Value of Values with Rich Hickey
InfoQ
4 comments from Hacker News
Along a similar line, I love Stuart Halloway's talk on Narcissistic Design - [VIDEO] Prefer APIs over data. Start with DSLs. Always connect (and never enqueue). Create abstractions for information. Use static typing across subsystem boundaries. Put language semantics on the wire. Write lots of unit tests. Leverage context. Update information in place.
Reading some of the comments here reminded me of a great talk by Stuart Halloway called Narcissistic Design.[1] [1] [VIDEO]
Nobody seems to have posted Stuart Halloway's Narcissistic Design yet, so I'll just leave this here. [VIDEO] Has some great insights and quips. "Nothing says 'screw you' like a DSL"
[VIDEO] This talk goes into many anti-patterns, but he gets to the real problem with SQL, that it is ONLY a DSL and lacks either an API or a fundamental information model to program against. Composability when working with a DSL is a nightmare. I also have been moving away from ORM to directly writing SQL, but lets be honest about the reasons that programmers are wary of working directly with SQL as they are legitimate issues.