I like this idea. I find it fascinating how many developers I've interviewed who still have not come across FizzBuzz, and how many of those cannot solve the problem. Some of the more interesting interviews I've given though have been with people who know the FizzBuzz problem, where I ask them to make the worst possible version of it that they can. It turns out to be more difficult than they think it will be, and a deeper thinking and communicating exercise than solving the simple FizzBuzz problem itself.
I opened the link thinking ”hah, what a gag!” But then I thought it’d be funny to try to find the core fizzbuzz logic. Turns out that it hits way too close to home, I just got really annoyed. Not sure what I expected.
As the original author, I apologize for your agony.
This is a common complaint from people I discussed the project with, and the obvious reason for the success of the project in terms of people contributing patches and issues.
But then I thought it’d be funny to try to find the core fizzbuzz logic.
The point is that there is no "core" logic anymore. It's been broken down and spread out over a dozen files, each of which does "one and only one (tiny) thing" according to the "best practices" of problem decomposition. Then all the pieces are glued together again using design patterns.
It does hit close to home. I've seen all that code in one form or another. The "adapter" that ignores exceptions made me chuckle though. But like enterprise code I've seen before I have no chance of finding that class again although I am sure it exists.
> As in most descriptions of it are annoyingly ambiguous.
My very first interviewer (intentionally) didn't spec fizzbuzz correctly. The real test was whether the candidate listened to the customer's/lead engineer's spec instead of jumping to conclusions.
Fortunately, I was just entering college and hadn't heard of fizzbuzz before. I passed the "test" but for the wrong reason.
Being purposely misleading then penalising those who are misled doesn't seem like a good hiring strategy, but then again, I've never tried to hire someone.
WordPress should include a cache switched on by default then you have to turn it OFF as an advanced setting. That'd be good for performance and the environment :-)
But using Wordpress is no more overengineering than buying a car. (Versus building your own 2 stroke engine because it's simpler).
Wordpress is under-engineering. It's what you default to when you don't want to do any engineering and just deploy the standard blog solution that everyone's familiar with.