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] - ▶ this video

in “Refactoring: How do I even start?” · View on HN

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: ▶ this video

in “Admitting That Functional Programming Can Be Awkward (2007)” · View on HN

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: ▶ this video

in “Ask HN: Is There a LeetCode for Refactoring?” · View on HN

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] ▶ this video

in “The Wrong Abstraction (2016)” · View on HN

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: ▶ this video

in “Programming: Doing it more vs. doing it better” · View on HN

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] ▶ this video

in “Ruby 2.5.0 Released” · View on HN

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

in “Ask HN: What books had the greatest effect on how you structure your code?” · View on HN

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: ▶ this video

in “Ask HN: What are some examples of beautiful software?” · View on HN

This is a great presentation about refactoring that may be useful: "RailsConf 2014 - All the Little Things by Sandi Metz" ▶ this video

in “Ask HN: How do you deal with 2000 line functions?” · View on HN

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

in “Factory Factory Factory” · View on HN

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: ▶ this 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]

in “Female Software Engineers and Startup Founders?” · View on HN

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] ▶ this video

in “The Wrong Abstraction (2016)” · View on HN

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] ▶ this video

in “Solid Principles: A Software Developer’s Framework to Robust, Maintainable Code” · View on HN

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

in “Why Swift Guard Should Be Avoided” · View on HN