RailsConf 2014 - All the Little Things by Sandi Metz

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] - [VIDEO]

You might want to see this: [LINK] Not really about production code, but still, some food for thought. Also this: [VIDEO]

This is a great presentation about refactoring that may be useful: "RailsConf 2014 - All the Little Things by Sandi Metz" [VIDEO]

That and Hammock Driven Development: [LINK] Both of these talks are in my top 5. Edit (okay, here are the other 3): * All the Little Things by Sandi Metz [VIDEO] * Programming is terrible—Lessons learned from a life wasted. [LINK] * 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: [LINK]

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: [VIDEO]

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" [VIDEO] 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 [LINK] 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.

Sandi Metz was already mentioned in this thread, so I present [VIDEO] where she shows how the little things can help.

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. [LINK] [VIDEO]

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 [VIDEO]

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" [VIDEO] Her blog talking more about the assertion: [LINK]

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: [VIDEO]

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] [VIDEO]

"Duplication is far cheaper than the wrong abstraction." — Sandi Metz ( [VIDEO] ) This talk by her is one of my favorites ever. Her ideas definitely made me a better programmer.

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] [VIDEO]

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] [VIDEO]

I don't have a full 'LeetCode' style example, but the Gilded Rose Kata teaches me something every time I try it. Original Kata: [LINK] Sandi Metz's Take: [VIDEO]

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: [VIDEO]

Strongly agree. For me the mark of a useful framework is that is reduces the complexity of the task you are trying to do. If it increases the complexity of the task, it isn't the right tool for the job! Choosing the right level of abstraction is the most important part of software engineering. If all you need is HTTP routing, then Flask is great, but every time I tried to use it for the kinds of things Django is great at (databasing, templating, forms), I had to effectively roll my own crappy version of Django. (Something something every sufficiently large C++ program has a poorly implemented version of LISP embedded into it.) I saw this dramatically demonstrated by an enormous Flask installation that would have greatly benefited from a little imposed structure. I bounced hard from that gig after being shown the code because it was going to be a massive pain to understand the poorly designed abstractions. But it wasn't even the maintainer's fault - it was pretty good code but it had only been designed by one person, both the abstractions and the business logic. And the abstractions were leaky simply because abstractions are difficult to design. The framework allows you to completely offload the architectural decisions underneath the framework to many person-years worth of design, bug squashing, and security fixes. How do I add headers to a request? Django has one opinionated way. Where do I put my database models? models.py and if you put them there you don't have to do any c

From personal experience, the gender disparity can feel daunting but it gets easier once you start building your network in the industry and getting more experience. In my days as an intern, some of my first mentors were women software engineers with exceptional technical abilities who were indispensable to their teams. Lots of colleges have clubs for women in tech where you can meet and be mentored by other women, and many tech companies have placed a heavy focus on hiring and retaining strong talent from underrepresented groups including women. As for women to look up to, I don't have an exhaustive list but here are a few that come to mind: - Sandi Metz: [VIDEO] - Melanie Perkins, co-founder of Canva - Ella Ehrlich: [LINK] Also, YC keeps a list of all of their women-founded companies (there are a lot more than you might expect): [LINK]

One of the many great takeaways from Sandi Metz's talk at Railsconf 2014: "Duplication is far cheaper than the wrong abstraction." [VIDEO] Worth watching in its entirety, but the quote is from ~13:59 in that video.