Jeff_Dickey

Agreed, but I'll just point out that works both ways. Devs "identify" with their default tool of choice, and too many coulda-been-GREAT tools try to be the Swiss Army Nuclear Ginsu Chainsaw of Code rather than the sweet hammer they started out as. Sometimes this happens to dominant tools in a category (such as Rails within Ruby); other times, it's happened to entire languages (PHP, VB, and many others; I once had to maintain a terminal emulator written in COBOL.)

As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.

Two of my guiding principles for development are mottoes I heard repeatedly from emergency medicine professionals:

1. "Don't just do something, stand there!" Are you sure enough that the first "obvious" response is going to do significantly less harm than good? If not, wait a second, think, and try again;

2. "If you don't write it down, it never happened." At least not the way you (think you) remember it, and what you do remember is lacking a detail that will turn out to be critically important. Having information that you trust, available at need in usable form, leads to dramatically better decisions out to several sigma from the mean.

"There's never time to do it right, but always time to do it over." I'm currently employed in one of the most pathological examples of this that I've come across in a 35-year career. Development using agile processes is a game-changer, but it's the worst of all worlds when the most essential things that make for agile development — like pairing, or small iterations — are cast aside because "we don't have time for that".

Difficulty of testing is a generally reliable indicator of a design that's in deep pain. [Growing Object-Oriented Software, Guided by Tests](http://www.growing-object-oriented-software.com) is easily one of the two or three most influential technical books I've read in my career — and the book's only five years old.

When I'm spelunking through some dank and dimly-lit Rails-model God Objects, I often fantasise about how things would be different if certain influential developers had read that book or one like it before setting out, and had taken the lessons to heart. Then I swap the batteries in my headlamp, and continue my descent.

I agree. The first app we wrote using CanCan, the `ability.rb` file (and the dozen files we factored out of that) grew to be... significant.

I love the idea of Pundit because it decouples all that as much as seems practical. I'm about to find out if theory informs practice or not...

I agree. I'd go so far as to call the non-"Classic" school the "OO Experienced" school — people who've had copious experience in SOLID OO development in Ruby and/or other languages, who are generally horrified by many aspects of The Rails Way, but find several of the tools and components useful. The apps developed by this school generally transition fairly quickly from The Rails Way apps, to apps that use Rails, to apps that use several components that are also used by Rails but with increasingly strict separation between the AR persistence/validation/nothing else layer and the domain model. The farther along that arc an app progresses, the more survivable it generally becomes for the team and the more flexible (and profitable) a tool for the organisation.

The Rails Way is fine for a prototype, or for an app that is so well-understood that the team know from the beginning will have sharply limited change in certain very-well-known areas. It's safe to say that the vast majority of the apps I've seen in my career do not fall into that category.