Industrial Logic

Knowing a lot of the early Agile people, I'd say your bit about "most people writing most about the various trends and ideas did so to mainly to make a buck" is both helpfully true and dangerously false.

There are definitely some people who say, "Oh, X is fashionable, so I'll jump in and become a thinkfluencer." Those people are dangerous. There aren't many, though; call 'em 10% or so.

There are plenty more people who jump in to participate but just don't understand the ideas very well. They're not really out to make a buck. They're mostly trying to help people; it's just that they have a poor understanding of how little they know. These people often do very well because their clients also don't know much, and really don't want to know much. This is the bulk of the market, say 75%.

But then there are 15% of people who are sincere, very smart, and deep thinkers. This is often a hindrance in making a buck. Their ideas are so radical (in both senses of the word) that a lot of their potential audience gets scared off. However, they are definitely worth listening to. Their solutions may not match your circumstances, so you shouldn't follow them blindly. But for me they're the ones most likely to trigger deep reevaluation of something I thought I understood.

My take is that the Extreme Programming community is mostly in that latter camp. If you're really looking for an approach with the values that you state, I'd encourage you to check them out. The original books, 15+ years…

I enjoyed the first edition immensely. Some folks are calling out that most of the refactorings are mainstream, but IDE integration doesn’t mean that it has become common practice or second nature to most engineers.

If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book.

Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference.

The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code.

Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)

That is not entirely true. GoF patterns have tons of examples in Smalltalk, which is as dynamic as Ruby/Python.

But they are more verbose and awkward to use in statically type languages, languages without first class functions (unlike Smalltalk, Ruby and Python), and methods like doesNotUnderstand, method_missing or __getattr__.

And languages with mixins/metaprogramming support can do pretty much all patterns in a much better way (this is easy to see on the paper[1] where Gregor Kiczales implements the patterns in AspectJ and see how much simpler they become when you have mixins).

The biggest problem with patterns is that people start with them, instead of refactoring to them when needed [2], which leads to a lot of over engineering (which is a form of premature optimization, and we all know what Knuth said about that).

Uncle Bob (creator of Selenium, author of Clean Code) talked about it recently: http://cleancoder.posterous.com/patterns-of-reality

[1] http://dl.acm.org/citation.cfm?id=582436

[2] http://www.industriallogic.com/xp/refactoring/

I recommend you to buy some proper books to get familiar with well written design patterns. Classics are "Design Patterns" from the Gang of Four (GoF), "Pattern-Oriented Software Architecture" by Buschmann et al. or "Enterprise Integration Patterns" by Hophe and Woolf which patterns are partly available on the website https://www.enterpriseintegrationpatterns.com/.

The first two books I consider almost a must read. Actually it's not about reading them but learning the patterns. More about this here: https://www.industriallogic.com/papers/learning.html

It's hard to understand what someone is really thinking and feeling. In the past I've found a lot of issues like can be traced back to safety, consider making safety a prerequisite [1]. Have you tried pair programming? Prioritizing the resolution of bugs over new feature work?

Try proposing some small experiments for the team to try over the course of a couple weeks that can pull your coworker into the team.

[1] https://www.industriallogic.com/blog/modern-agile/