HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
RailsConf 2014 - All the Little Things by Sandi Metz

Confreaks · Youtube · 6 HN points · 24 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Confreaks's video "RailsConf 2014 - All the Little Things by Sandi Metz".
Youtube Summary
Theory tells us to build applications out of small, interchangeable objects but reality often supplies the exact opposite. Many apps contain huge classes of long methods and hair-raising conditionals; they're hard to understand, difficult to reuse and costly to change. This talk takes an ugly section of conditional code and converts it into a few simple objects. It bridges the gap between OO theory and practice and teaches straightforward strategies that all can use to improve their code.

Sandi Metz, author of "Practical Object-Oriented Design in Ruby", believes in simple code and straightforward explanations. She prefers working software, practical solutions and lengthy bicycle trips (not necessarily in that order) and consults and teaches on all things OOP.

Help us caption & translate this video!

http://amara.org/v/FG0O/
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Sandi Metz helped me start using OO and not just write procedural code in an OO language.

Nothing is something https://m.youtube.com/watch?v=9lv2lBq6x4A

Poly want a message

https://m.youtube.com/watch?v=XXi_FBrZQiU

All the little things

https://m.youtube.com/watch?v=8bZh5LMaSmE

Jul 03, 2021 · 2 points, 0 comments · submitted by thunderbong
I _really_ struggled to not use contrived examples when teaching OOP. It was very hard because you don't really need it until your application becomes non-trivial so I see why all the college classes use cars & trucks or whatever.

I think I ended up going with a Player API with tapes, records, CDs etc. Some could skip, others only fast-forward. I was still unhappy with it, but it was better than most examples.

I like to point folks at writing an IntelliJ plugin. I find that some of the best architected OOP programs become nothing but a collection of plugin interfaces and base classes.

But you really need to understand "is a" vs "has a", not burn your base class, let architecture emerge following the rule of 3, rather than quickly jumping on the wrong abstraction to fight duplication.

Sandi Metz really says it better than I can: https://www.youtube.com/watch?v=8bZh5LMaSmE

catlifeonmars
If it helps, IMO inheritance is the least interesting feature of OOP. Programming with interfaces is a much more compelling story. A concrete example that is probably small enough to fit within an article or class is a 2d physics engine, where object positions, velocities and accelerations are updated in a loop.
I don't have a full 'LeetCode' style example, but the Gilded Rose Kata teaches me something every time I try it.

Original Kata: https://iamnotmyself.com/2011/02/14/refactor-this-the-gilded... Sandi Metz's Take: https://www.youtube.com/watch?v=8bZh5LMaSmE

I also (want to) understand the article this way, but I think the article is a bit vague about this point. It focuses on Programmer X, who is coming after many iterations of trying to retrofit features into a very wrong abstraction.

The article agrees that the abstraction was useful when Programmer A wrote it, but it remains vague about whether Programmer A's judgement was correct at step 2 or 3!

I'm not quite sure what Sandi Metz is thinking right now, but the original 2014 talk[1] linked in the article is pretty clear about _keeping the duplication_, and _waiting for the right abstraction_. This statement sounds more in line with the Rule of Three, or the Go proverb 'a little copying is better than a little dependency', which is what people are arguing here.

Personally, I believe that any non-trivial duplication should be eliminated at the very first chance, to avoid unintended business logic divergence. I find the later case more risky than having to deal with the wrong abstraction, since - as Sandi eloquently explains here - wrong abstractions can (and should!) be refactored.

[1] https://youtu.be/8bZh5LMaSmE?t=893

addicted
> but it remains vague about whether Programmer A's judgement was correct at step 2 or 3!

Which emphasizes the OP’s point that the article isn’t about what happens at steps 2 or 3 at all. So it’s not concerned with whether the judgment there was right or wrong.

Sandi mentions this during a talk she gave on refactoring a few years ago. [0]

It’s a great little video for showing junior developers how a messy bit of code can be cleaned up with a few well chosen OOP patterns (and a set of unit tests to cover your ass).

[0] https://youtu.be/8bZh5LMaSmE

voodoologic
I'm very partial to this talk about proper abstraction (and not just for junior developers): https://www.youtube.com/watch?v=OMPfEXIlTVE
Jan 12, 2020 · ryanwinchester on Goodbye, Clean Code
Been using mostly Elixir full time (w/ some JS here and there) for the last 3 years.

Talk link: https://youtu.be/8bZh5LMaSmE

xwowsersx
Thank you.
Jan 11, 2020 · abvdasker on Goodbye, Clean Code
"Duplication is far cheaper than the wrong abstraction." — Sandi Metz (https://youtu.be/8bZh5LMaSmE?t=891)

This talk by her is one of my favorites ever. Her ideas definitely made me a better programmer.

Changing an existing class (modification) is possibly bad, because it can introduce bugs. The code was working, you made a change, oops!

Adding a new class (when the code was written to be extensible) should prevent that.

See for example [1] where Sandi Metz shows how to rewrite some incredibly complex code to make that possible.

[1] https://www.youtube.com/watch?v=8bZh5LMaSmE

Sandi Metz does a far better job explaining the proper use of OOP in this video: [0]

I highly encourage anyone with doubts about OOP to actually complete that Kata.

In short, inheritance should be confined to removing conditionals in problems with shallow-wide [1] inheritance graphs, where things truly "is-a" thing, not "have-a" thing [2]

Real life examples I've encountered: * buttons in a toolbar implementing a command interface * database drivers extending a base implementation * web-server endpoints extending a base implementation

Some of the most complex software in the world is currently modeled using OOP. If one is ever in doubt, look into creating plugins for IntelliJ. The whole program is a massive exercise in OOP modelling, and it works pretty well (if not a little slow some times) [3]

[0] https://www.youtube.com/watch?v=8bZh5LMaSmE [1] http://cek.io/blog/2014/05/26/poodr-ch-7/ [2] https://stackoverflow.com/questions/2218937/has-a-is-a-termi... [3] https://www.jetbrains.org/intellij/sdk/docs/basics/getting_s...

This line of discussion reminds me of a great quote by Sandi Metz, who's pretty well known in the ruby community for harping on the topic. One thing I saw in a talk of hers that really stuck with me: Repetition is preferable to the wrong abstraction.

The first thing that's drilled into a new programmer is DRY. It's easy to understand and it works reasonably well. The next step up seems to be knowing when _not_ to roll stuff up, and how to tell when you're looking at a distinct piece of logic that needs to be reified into it's own entity or function.

EDIT: The Sandi Metz talk I mentioned: https://www.youtube.com/watch?v=8bZh5LMaSmE

I'm a huge proponent of this concept. The goal is to be able to build and iterate as fast as possible. Most of this is achieved when new folks can step in and understand the code right away. Needless abstraction slows this down and makes the app more brittle to changes in response to customer/client inputs.

Sandi Metz had an awesome presentation about this during a Rails Conf.

"Duplication is far cheaper than wrong abstraction"

https://www.youtube.com/watch?v=8bZh5LMaSmE

Her blog talking more about the assertion:

https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

Define "technical". But when it comes to programming I always enjoy Sandi Metz's talks. I can highly recomend this talk she made at the RailsConf in 2014, about taking an ugly beast of code and turning it to something more digestable and beautiful https://www.youtube.com/watch?v=8bZh5LMaSmE
patrickdavey
Totally agree, Sandi is awesome, all of her talks are worth watching. I quite like the the one where she tells the future https://youtu.be/JOM5_V5jLAs . I feel that kind of step change will shortly be with us (if we're not already in the middle of it)
OJFord
In the middle of a step change?
Sandi Metz did a great talk on this that can be summed up in one really good quote

> Code duplication is far cheaper than the wrong abstraction.

https://youtu.be/8bZh5LMaSmE

Dec 27, 2017 · andrei_says_ on Ruby 2.5.0 Released
You may enjoy Practical Object Oriented Design with Ruby by Sandi Metz. Speaks about OO software design in very clear and easy to grasp way.

I often share it with non-ruby devs because it’s about design much more than it is about ruby.

Here are a couple of talks by the author which examplify her style of thinking and approaching problems.

https://m.youtube.com/watch?v=29MAL8pJImQ

https://m.youtube.com/watch?v=8bZh5LMaSmE

Sandi Metz was already mentioned in this thread, so I present https://www.youtube.com/watch?v=8bZh5LMaSmE where she shows how the little things can help.
Jun 30, 2017 · 1 points, 0 comments · submitted by yamaneko
These talks are a little skewed to the game/high performance programming side of the art, but still very interesting in general. Of the ones I've already seen I really like Mike Acton's talk.

Since this has become such a nice thread some additions I'd add:

* Sandi Metz going through the Gilded Rose or "All the small things"

https://www.youtube.com/watch?v=8bZh5LMaSmE

I already subscribed to her programming style and the general Ruby TDD/BDD movement, but this talk captures all the important values in a single example. I think it made my programming style no longer based on vague things like experience or intuition, but just on concrete merit shown in this talk.

* Matthew Brecknell demonstrating Hole Driven Development

https://www.youtube.com/watch?v=52VsgyexS8Q

The programming style demonstrated in this video is a real mind bender. I think most Haskell programmers use a weaker version of this, Matthew takes it to the extreme. I didn't adapt this style, I don't think it's practical, but it's the sort of thing that some person someday will incorporate in some more comfortable way in a new language or platform as a revolutionary feature.

chriswarbo
> I don't think it's practical, but it's the sort of thing that some person someday will incorporate in some more comfortable way in a new language or platform as a revolutionary feature.

As mentioned below, this can be used in languages like Agda and Idris; they also give you proof search, which tries to automatically fill in the holes from available definitions. This works well for 'proof objects' (the name given to values which only exist to satisfy the type checker), but requires caution for values with 'computational content' (those values which can effect the resulting computation).

Pretty much all Haskell code (except the really wacky astronautical stuff) has computational content, so there are fewer "obvious" obligations to fill in than would appear in a proof (in fact, due to laziness and lack of totality, we can safely use 'undefined' for all proof objects, since they'll never be pattern-matched!).

For example, if our function needs to return a list (e.g. if we're writing a function like map, filter, iterate, replicate, cycle, etc.), a proof search will immediately give us the empty list '[]', which is correctly typed but probably wrong.

For Haskell, tools like djinn can get you a little hole-filling automation, and I think that Emacs modes like ghc-mod and intero support calling out to djinn (I can't test this, as I can't get either to work on NixOS :( ).

For a little more work, you could write properties for QuickCheck (/SmallCheck/LazySmallCheck/etc.) to constrain the behaviour, which would allow trivial solutions like the empty list to be ruled out automatically. If you're a TDD disciple, then you already wrote these properties, so this part would actually be free (as long as the automation tooling exists).

At that point you're basically doing inductive functional programming, so tools like IGOR2 or MagicHaskeller might be useful to plug in as well.

erikbye
For some, there might be some valuables on these interviews:

https://www.youtube.com/watch?v=QVpSIdWE0do&list=PLEMXAbCVnm...

Again, it's game dev oriented, but there are good general advice as well, here and there.

Mike Acton is on there too. Jonathan Blow, Ron Gilbert, etc.

In general, I think more programmers should be concerned with learning how things work at a deeper level than the API for whatever web framework they are using. Web applications are god-awfully slow, it's like the programmers behind them just don't give a shit about performance, at all. It's not that much better on the desktop side either.

rntz
The "hole-driven" development style originated in dependently typed languages such as Agda and Idris, which I imagine Matthew's video was inspired by. So if you want to experience it right now, go learn Agda and use agda-mode in emacs. (Probably something similar exists for Idris. I don't know whether Coq has a notion of "holes".)
chriswarbo
idris-mode for Emacs does similar tricks ( https://github.com/idris-hackers/idris-mode ) and I've heard it's very nice.

The Idris REPL itself can do hole-based programming too, which can then be dumped out to a file (:m to list holes, :p to prove a hole, :a to write proofs to disk) http://docs.idris-lang.org/en/latest/reference/repl.html

greydius
> The programming style demonstrated in this video is a real mind bender

You might also be interested in:

https://hackage.haskell.org/package/djinn

Djinn writes the code for you. Cut out the middle-man. (Don't show your boss.)

vvanders
> These talks are a little skewed to the game/high performance programming side of the art, but still very interesting in general.

I get the chance to interact with a pretty wide range of software engineers, the thing that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it(and have the time to exploit it).

It's almost like they don't teach it in school or something, I agree there's a lot of gamedev/perf stuff but that lines up with my experience of things that change the way people approach programming.

Szel
> that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it

Could you point to some sources?

chiefalchemist
+1
tinco
This is the paper people usually use to explain some of the performance benefits you could reap, besides the talk about row vs column based performance:

https://www.akkadia.org/drepper/cpumemory.pdf

Note that I wouldn't really recommend it unless you're really going to do low level programming for high performance. It's super long, explains all the details, if you've got a basic CS college education you should know most of it already anyway.

If you're just a web developer this won't actually help you as most of this improvements have already been done in the parts that matter (i.e. your database, your operating system, your interpreter and perhaps your application server).

Watch this talk [1] if you want to see someone transform horrible code into 10x code.

[1] https://www.youtube.com/watch?v=8bZh5LMaSmE

Sep 14, 2016 · xwvvvvwx on Ask HN: How to Learn OOP
Sandi Metz is great.

This talk is such an amazing example of clear thinking:

https://www.youtube.com/watch?v=8bZh5LMaSmE

vinceguidry
I actually watched that talk twice. The technique of introducing a seam set off light bulbs in my head that didn't go off the first time I watched it.
Sep 14, 2016 · rimantas on Ask HN: How to Learn OOP
More code, more complexity? See this: https://www.youtube.com/watch?v=8bZh5LMaSmE
dreta
The speaker just introduces more OOP complexity into already complex OOP code. All that’s going to do is make the code even harder to modify or step through.
Jul 30, 2016 · 2 points, 0 comments · submitted by xwvvvvwx
Not working software per se, but I think there's a lot of beauty in the way Sandi Metz demos a refactoring of a thing called The Gilded Rose in this video:

http://m.youtube.com/watch?v=8bZh5LMaSmE

Feb 26, 2016 · hire_charts on Rich Hickey Fanclub
That and Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

Both of these talks are in my top 5.

Edit (okay, here are the other 3):

* All the Little Things by Sandi Metz https://www.youtube.com/watch?v=8bZh5LMaSmE

* Programming is terrible—Lessons learned from a life wasted. https://www.youtube.com/watch?v=csyL9EC0S0c

* Some talk I saw by Dan McKinley on making Data-Driven decisions. I can't find the original video, but here's a really similar one: https://www.youtube.com/watch?v=SZOeV-S-2co

solipsism
Give us the rest, please!
hire_charts
Okay! (see above)
josteink
Completely unrelated: Alan Kay - the power of simplicity

https://youtu.be/NdSD07U5uBs

Easily over of the most thought provoking presentations I have seen recently.

This is a great presentation about refactoring that may be useful: "RailsConf 2014 - All the Little Things by Sandi Metz" https://www.youtube.com/watch?v=8bZh5LMaSmE
You might want to see this: https://www.youtube.com/watch?v=npOGOmkxuio Not really about production code, but still, some food for thought. Also this: https://www.youtube.com/watch?v=8bZh5LMaSmE
moonshinefe
She seems like a great speaker, will bookmark for later. TY.
mercer
Her book "Practical Object-Oriented Design in Ruby"[1] is also quite good

[1]: http://www.poodr.com/

SwellJoe
Those are really excellent. I don't work in Ruby, but her explanations of OO design and refactoring are among the clearest, and most concise, I've ever seen. I'm gonna be watching her talks for the next couple hours, I suspect.
Sandi Metz talk "All the Little Things"[0] is amazing for understanding the general concepts around refactoring OOP code. It's ruby centric, but the concepts are applicable to all OOP languages. The most interesting part is the fact that during the refactoring process you should actually increase the amount of code and complexity to eventually consolidate and aggregate it down. This as opposed to simply trying to delete/mutate code.

[0] - https://www.youtube.com/watch?v=8bZh5LMaSmE

Feb 19, 2015 · 1 points, 0 comments · submitted by zachrose
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.