I've been using this method for about a week - great outcomes from it so far: clear, clean language that sounds like something someone would actually write.
I'd put the shift even later than that. 2015 maybe. I think 2008 redirected a lot of people who would have gone into "Business" in the abstract towards tech, eroding the prior engineering culture, and then it took a few years for that crowd to establish themselves as a relevant voice in the community.
Looking back, the reaction to Aaron Shwartz's death in 2013 was, IMO, indicative of the older culture. It definitely felt like a minority viewpoint by the time Covid rolled around. So, somewhere in there.
I don't think you can plausibly claim that the US was a leader in technology until the 20th century, which is long after the US started having enormous amounts of immigration.
> ...to develop the powerful abstractions that then allow us to do much more, much more easily. Of course, the implicit wink here is that it takes a lot of work to be lazy
This lines up with YAGNI, but most people believe the opposite, often using YAGNI to justify NOT building the necessary abstractions.
The counter-argument is that people build abstractions they deem necessary but aren't, and then they're married to that premature architecture quite often. That's what YAGNI is there to advise against.
I don't think what Fowler says here is in favor of saddling the early versions of your system with abstractions before you actually seen its use in practice, and its needs over time as requirements and conditions change.
From this "Laziness drives us to make the system as simple as possible (but no simpler!) — to develop the powerful abstractions that then allow us to do much more, much more easily." it's clear that when he talks of abstractions he means of very basic, and as simple as possible, building blocks. Like having core, orthogonal, principles in the system.
Not the kind of piling of software and pattern design abstractions e.g. the Java land in the past used to build.
reply