We clearly need to get back on track. The source of this conflict:

You now know that this assertion is complete nonsense. That was my entire point. It's been made. You admit as much with nonsense like this:

Read that again: "altering the target optimal performance" The word "optimal" there loses all meaning. It should read as simply "target performance". There is either an optimal solution or there isn't. Why not just say "the best possible solution is whatever I say it is". It's more honest, and just as convincing!

On science, you give this silliness:

Science is many things. You define science as a body of knowledge. Science can also be defined as a method of inquiry, as a community, and simply to mean 'the study of'. I expect middle-school kids to understand something that basic.

The "science" part of "computer science" is science in 'the study of' sense. As a discipline, it's essentially a branch of mathematics.

You also don't seem to understand what is meant by 'art'. I'm going to guess you're an autodidact. Am I right? I can't imagine that an educated person would make such an absurd statement.

How disappointing. At least you tried. How do you know that your solution is the fastest, lowest memory solution possible? How do you know that your "best practices" are really the "best" and that there aren't better options?

Since you mention it, how do you know that the language or platform selected is capable of producing the optimal solution? You mention using Java a good bit, so you know that you're already adding a lot of overhead and thus very unlikely to produce a mythical "best possible solution" given your performance and memory requirements.

See, there is no such thing as the "best possible solution". What you're describing is an "acceptable solution" given a set of constraints, many of which (like your silly "best practices" which change with incredible frequency) are just folk-wisdom. They're not scientific, mathematical, or objective in any way. Your other constraints (memory and speed) are impossible to meet as you can't tell if there is a faster solution that uses less memory.

Instead of trying to win an argument here, reflect a bit. Particularly on how readability factors in to your above criteria. Are those criteria subjective or objective? Can they be measured? Are you really measuring what you think you're measuring or do your methods merely quantify something you believe to be related? On things like memory and cycles, how do you know that they are as low as possible and that there aren't different approaches that you could use to minimize those?

Further, when you trade memory for speed or speed for readability how do you know that your decision will lead you closer to this alleged "best possible solution"?

Okay, I'll play. What coding standards are necessary to achieve the "best possible solution" for a given problem? How were these determined?

If you'd rather: How can we determine that we've arrived at the "best possible solution"?

Nonsense. Though that silly belief is a big part of the delusion.

There are a lot of factors to consider when writing a computer program. Some (but not all) of those factors can be quantified. How best to balance those is also deeply subjective. For example, is a fast program that uses little memory but is difficult to read and maintain better or worse than a fast program that uses more memory but is easy to read and maintain?

I don't know that I really need to explain this further. It's pretty obvious that there is no such thing as a "best possible solution" to a given programming problem. To believe otherwise is, quite simply, delusional.

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.