Apparently people need to be reminded that "Don't Repeat Yourself" is more a guideline than a rule. So "The Rule of Three" is a way to do that (although I find ironic it's called a "rule").

It's indeed a nice little pattern to use when the type system allows for exhaustiveness checks of destructure operations. Allows to gracefully handle extension of structs in the future.

A good explanation of why the concept is important, also comes with a nice list to get started.

The Adaptive Model is a lesser known design pattern. Like any other pattern make sure you are in the right context to introduce it. Especially this one as it can get really verbose. This article shows a refactoring path for moving from imperative logic to adaptive model.

Good reminder that refactoring isn't necessarily the end of a cycle. It can also be before you add a feature.

There are many opportunities to redactor. This one is aligned with Kent Beck's quote: "first make the change easy, then make the easy change".

Interesting trick to help with project wide renames for Python codebases.

Since there's a clear tendency in the developers I meet to "extract at all costs", this is a good reminder that sometimes you need to inline the code first. This very often brings better clarity in the context of use. In turns this leads to a better final extraction.

Nice balanced view on some of Rust characteristics. This is much less naive than some of the "Rust is great" posts out there.

Definitely a good approach for larger refactorings or preparing major upgrades.

Interesting idea on how to schedule large refactorings and make sure they happen over time.

Review of the newest book from Kent Beck, I'll probably check it out and read it.

Definitely this. One is more painful than the other though. It's a question of paying small price over tine vs paying a big cost later.

Nice refactoring and design pattern catalogs.

Looks like it completes Comby nicely for the search only case.

Looks like an interesting tool for scripting refactorings. Seems lightweight and more forgiving than Semgrep, looks like there's space for both in our tool belts.

A good set of skills to develop to bring technical changes to a project. It doesn't need to be overwhelming or a fight. If you doubt, if you have empathy and if you slice the proposals it can become doable and help the people around you.

This is a clever and important use of =delete which I sometimes miss in other languages.

Good point, this little wisdom from Kent Beck goes further than just code and refactoring.

Very interesting musing about the technical terms we often use wrongly and how it difficult it is to be understood.