Don't be foolish. Dogmatic adherence silly acronyms at the expense of readability is a bad thing. You often end up with more code, not less, trying to avoid any and all redundancy. If it's cleaner and easier to read and maintain, it's worth the exchange.

Let's look at your justification for your dogmatism:

What you've written here, is that if a developer makes a mistake modifying code they don't understand, you'll have broken code. It doesn't look that strong now, does it?

Further, I'd argue that adding more, likely more complicated, code to avoid a tiny bit of redundancy is far more likely to bring about those circumstances where a developer is going to modify code they don't fully understand.

Have you ever played code golf? The idea is to make the shortest possible program that meets some requirement. The most common strategy is to start with a normal implementation and then find ways to reduce the codes size. Essentially, it's about eliminating redundancy. The results look really impressive, short and compact code that does a lot. They're also impossible to read and maintain!

What I'd challenge you to do is find some short bit of code you've written that you think is particularly good, then play code golf to reduce its size. I can guarantee that you'll find plenty of redundancy in function of which you can take advantage to reduce the code size. I'll also guarantee you that your code will be less readable and far more difficult to maintain.

If you really are a born-again acronymist, you'll happily take DRY to its absurd conclusion and golf your way to an unmaintainable nightmare. My guess is that you'll quickly come to your senses and realize that DRY is really just a bit of folk wisdom. It's good to avoid a lot of redundancy (somethings things should be made more generic) but that it's not truy evil, and can sometimes be helpful. Particularly when it makes your code easier to read.

Speaking of making code generic, that's not always a good thing either. You've probably seem this yourself, where a programs size and complexity were dramatically increased by trying to make everything as generic as possible (usually justified as making the code 'reusable'). While a joke, FizzBuzz Enterprise Edition makes my case here nicely.

Keeping code simple and readable is far more important than any fly-by-night acronym you'll run across.

No, it's not science. (It doesn't even remotely resemble science!) Neither is it an application of science, for obvious reasons. I'll maintain that it isn't mathematics or an application of mathematics as well, as while some math is used, it's not where the developers effort is focused. (If you don't like that, ask yourself why there isn't an algebra for computer programs.)

It's more in line with arts and crafts. You'll find far more similarities to painting or sculpting in programming than you will mathematics or science. Interestingly, you'll use quite a bit of math is both painting and sculpting. (You may even find some applied science in those.)

It's just delusional thinking to make some developers feel better about themselves. Consider how many developers don't understand basic logic, despite believing that logic is a fundamental aspect of the work that they do! You might be one yourself. Grab an undergraduate textbook on logic and give it a go. You may find yourself surprised.

I'd never trade readability for "elegance" or, worse, "performance".

Code golf may be fun, but it needs to be kept very far away from everything outside those games.

Oddly enough, I've seen that cause more problems than it's solved.

It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.

Even when used correctly, I've seen some pretty impressive code-contortions to avoid even a very small amount of duplicate code. Sometimes, it's okay to just do a check twice. As long as the code is easy to read and modify, you're fine. Really.

But that's the problem with programming, isn't it? It's little more than wishful thinking and folk-wisdom. That would be okay (it's an art, after all) but too many developers have deluded themselves in to thinking it's more in-line with mathematics or engineering. They've convinced themselves the cute little acronyms they repeat to one another have some objective, rational, basis and must be obeyed at all cost.

It's silly, really.

Okay. Good for you? What does that have to do with the silly point you were making?

Moving on to something relevant:
$7k isn't exactly a big return over a period as short as two-months. Even $47k over a year isn't great working for yourself, by yourself, in most places. It could be okay if you live in an area with a low cost-of-living, you were single, worked out of your home, and didn't need health insurance.

If you hire anyone, expect that 7k to vanish in short order. Even at $47k, you'd be lucky to pay a second developer for more than a few months, even at a very low rate.

The point? The "hidden assumption" that development takes a year is nonsense.

Whatever helps you sleep better at night.

I didn't miss it, it's just total nonsense. I'd call it wishful thinking from socially inept basement-dwellers. They get to pretend that their poor hygiene and lack-of-success with women indicates that they're really super-programmers.

You're confused because all you see are monopolies and near-monopolies. Don't panic. That's what an under-regulated free market naturally produces.

Let's look at that again:

"$7,000" ... "The assumption it takes a year"

I highly recommend that you talk to HR about your compensation.

Well, they were right. They're still right. Just head-to-head the iPad against something like the Surface Pro and you'll see why they mean.

No, I was making fun of you. See, you believe that programming is just too difficult for women yet believe that the mentally challenged are qualified. I'm pointing out that it's easier than it has ever been -- a point to which you're sure to agree as you hold the absurd belief that mentally handicapped people are attracted to the profession.

It is possible that you're a mentally disabled programmer, and simply believe that your personal experience is common. That I'll believe.

No. That's the problem. The question here is "why?"

My guess? The industry is a cesspit. It's hostile to all, but to women in particular. Hobbyist communities, online forums, and (particularly) OSS projects are even worse. It sucks for men, sure, but it sucks even more for women.

Think about the shitheads that make your workplace a living hell. Now imagine that, while you're physically weaker, they're also making unwanted sexual advances and, possibly on occasion, "accidentally" groping you. On top of all that, regardless of your actual performance, you're considered to be half as good as the worst guy on the team.

Does that sound like your dream job?

Not exactly. Well, not even close!

While it's true that most women have similar opportunities, they also face dramatically different obstacles.

People like you, for example.

A fitting prelude to your post. At least you were honest about what followed. In case you were actually serious:

Neither autism nor any of the particular metaphysical assumptions you offer are relevant to the topic.

Further, while it's true that the average computer programming job in the 1960's is different than it is today, it's gotten significantly easier. So simple, in fact, that many mentally handicapped men, as you point out, opt for a career in programming.

Congratulations, you've missed the point!

It wasn't easy, I'm sure, but you've done it. You even managed some outrage. It's rather impressive, really.