Maybe it has something to do with the nature of the business of game programming, where most projects are only developed and maintained for a year or two and then the team has to move on to the next big project in order to pay the bills. In a context like that, it can be easier to make the case that monkey patching might be a better use of resources than refactoring.

Generalizing this to all of software development is still a bit presumptuous though.

Yet, he seems to be giving black-and-white picture of what constitutes bullshit to non-technical people.

Have you read the article? He's nuanced on refactoring in a manner that the originator of this thread doesn't describe.

When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept.

However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.

The refactoring section is one of the better parts, though. The article is very black-and-white on "generic version", "framework", "platform independent", and so on.

I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't.

Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.

Right and I'm just pointing out that the part on refactoring is way more nuanced than people were giving it credit, very often in a manner that suggested they were commenting on something they hadn't even read!

It will always be possible to accuse an article or even a book of being light on details. It is after all some pointers and not a scheme to make a non-technical manager technical. Learning anything takes more than reading at surface level, particularly of a clearly introductory article. The principle of charity goes a long way to smoothing out the inner pedant.

> The principle of charity goes a long way to smoothing out the inner pedant.

Certainly true, and I do think people skipped the section on refactoring. But I guess my real complaint here is that the article itself seems to advocate against the principle of charity!

Asserting that generic versions and frameworks are inherently 'red flags' that someone doesn't know how to do their job doesn't seem like an inducement to more reading, it seems like a misleading absolute. I got that feeling throughout the whole piece, for instance with the implication that memory limits are key in all tasks.

It was either very domain-specific advice (I know the author came out of game design, which fits his list better than general software), or vastly overstated advice.

I come from a games background as well so am probably deaf to how domain specific things are. But people spending far too much time making something too generic or an extensible, pluggable doodad with its own DSL rather than creating the simple, dumb version you actually need is actually quite common IME. Engine code (which is partly framework building) is very susceptible to overengineering and attempted future proofing.

I don't think they're being introduced as red flags to say "call bullshit on this and don't do it" but to be aware in the following cost-benefit analysis.