The overweight cat was feeling drowsy having eaten a large meal, and lay down on the mat to sleep.
Concise, joined up, complete.
And yet, your re-factoring of this very simple story contains several subtle flaws. First of all, "overweight" generally implies someone who is thinner than someone who is "fat". Someone who is "drowsy" is just on the threshold of becoming "sleepy". In the original story, the cat sits on the mat: it doesn't lie on it. In the refactored version, the meal is correlated with sleepiness: in the original, direct causation is explictly spelled out.
If some zoologist spent months coming to the conclusion of causation, it's a serious loss of domain knowledge to downgrade the information back to mere correlation. Similary, if overweight cats sit rather than lie, it may imply something important to future zoological researchers. As you point out, it can be tricky to manage code: the K.I.S.S. principle of engineering should apply wherever possible.
Software constitutes some of the most complex creations of man. Writing software is one of the most challenging endevours man undertakes,
I disagree. There are several domains far more rich and complex than computer programming, and yet we manage complexity in them on a regular basis. Physics is nothing less than the formal study of the entire physical universe. Modern medicine is the study of how to maintain over six billion uniquely distinct lifeforms in working order, each one of which is a composite of a myriad different kinds of sub-lifeforms, and miniature ecosystems. Computer Science is the formal study of algorithms, including both their design, and formal proofs of correctness. It's only a tiny subset of the vast, mind-boggling complexity of mathematics. Non-commutative algebra is complex. Quantum mechanics is complex. Computer Science is complex. Computer programming, especially as applied to typical business purposes, is not so complex.
Programming is largely just a matter of encoding: translating known algorithms into existing computer languages to solve real world business problems.
and requires education, skills and experience to do well.
This is true of almost any discipline, from basketweaving to automotive repair. It's a bad idea to trivialize any form of learning.
You would not employ a lawnmower service apprentice to work on your Lexus or Mercedes.
I most certainly would. If a "lawnmower service apprentice" (or any other unskilled person, for that matter) can't re-fuel the vehicle, check the oil, top up the fluids, or change a tire, then the car design is too complex.
If a "semi-skilled" automobile mechanic can't repair the car, the design is also flawed. Remember, mechanics are maintenance workers: they're not all formally trained automotive design engineers. They don't need to be. I doubt either my cousin or my uncle could calculate the stopping distance of my car based upon the co-efficient of friction of the brake pads and the related engineering equations: but they certainly know how and when to replace them. That's because automotive design engineers deliberately take maintenance into account: they make parts easy to replace, they provide "dumbed down" (i.e. "useful") replacement part and part substitution tables, and they document everything at a level the mechanics can understand. They specifically don't assume they're writing for someone with an engineering background.
Or a flight attendant to fly your 767.
Modern airplanes are so well engineered that they almost fly themselves. A flight attendant with minimal training (or more likely, minimal coaching from the control tower), could active the automatic landing systems in an emergency. That's because the systems are well designed, and simple.
Pilots hate complexity. The main goal of running an airline is to force the pilot to think as little as possible. I know, because I worked for the airline industry for 2.5 years, providing data for the pilots to take off and land. The goal was always to make everything as consistant and obvious as possible, because every time a pilot has to make a decision, there's a small chance he'll make the wrong decision. If he doesn't have to plan, he can focus all his attention on making his execution perfect.
Nor a med. student to perform open heart surgery.
Nurses, not doctors, take blood pressure, throat swabs, and perform other mundane operations. My family doctor doesn't have the skills of a heart surgeon, but he's certainly not useless. In medicine, again, a tiered approach manages complexity in a cost effective way. If everyone in the hospital absolutely had to be a surgeon, because "medicine is complicated", then we could only afford one or two hospitals per country. There would be surgeons sweeping the floors. It would be a pointless waste of talent.
Why would you employ a 14 y/o to edit anything important?
Why not? If the work is within their level of competency, then it's cost effective to hire them, since they tend to work for lower wages. Sound business practices dictate that I should hire the person who will do the required job, for the lowest wages. I don't care how smart my janitor is; I just need clean bathrooms.
Equally, employing unskilled, or semi-skilled persons to maintain your business software, and deskilling your programmers to write baby code in order that you can, is stupid and counter productive.
I disagree completely. I've shown that there are tiers of competency throughout the rest of industry, for reasons for cost-effectiveness, and maximizing the productivity of the true experts. I see no reason why programming should be different, here.
After all, aren't all computer programmers in some sense just "semi-skilled" computer engineers: unaware of all the electronic complexities of the circuitry and hardware that they operate? Call it "dumbing down" if you like, but the more common term is "abstraction", and it lies at the heart of how we manage complexity, both within and outside our field.
The term "baby code" is just plain perjorative: all code must still meet its full business requirements, or it's useless. Code that fills the required business need, and is easy to maintain is correct code. Anything else is not.
It's not "de-skilling" a programmer to teach him to express himself clearly. After all, programming is almost entirely about clear, unambiguous specification of requirements: both to the machine, so that work is carried out correctly, and to fellow programmers, so that the specifications are obvious and easy to modify.
If you dumb down the code, the maintenance programmer will never aquire better skills.
I disagree. Training programs for staff should not be carried out on mission critical systems.
Supervise their work and train them.
If I have to pay a senior programmer to supervise each line of code a junior programmer writes, it's equivalent to paying the senior programmer to write it for me. The senior programmer is still doing the real work: the maintenance programmer is being trained for free on company time. Mentoring may be one useful form of training, but it's certainly not the only kind, nor is it guaranteed to be the most effective.
The rewards will outweight the costs.
That's not necessarily true. Could I have hired a more skilled programmer for the cost of free training I'm offering the maintenance programmer? Could I have taught him the equivalent skills in some other way for less money? If so, then I'm wasting time and money bringing him up to speed by mentoring him.
And if I can teach my senior programmers to write clearly in the first place, 90% of the time I'll be able to let my junior coder just fix things. 10% of the time, he'll have to call in someone more senior to explain things, but the cost savings are obvious. I'm not paying the surgeon to watch the janitor sweep the floors.
No one needs to know that you passed grade 13 English with a 97% average"
Then why is your highest priority item?
"As others have mentioned, spelling and grammer are very important. Learn to express yourself in English, first."
There's no contradiction: good spelling and grammar are very important. Unfortunately, deliberately using a complex vocabulary will often give you good marks in high school English. However, you'll still fail any technical writing course you take, if your vocabulary choices confuse your target audience. Computer code and comments are a form of technical writing: it's not about creative personal expression, except perhaps for code written at home for fun.
In the business world, confusion costs money.
To further clarify: people should know that you're fluent in English, or rather, it should never become obvious to the reader that you're not. And they certainly shouldn't have to suffer through a pompous display of unnecessary vocabulary to just to understand your comments, or your code.
--
Ytrew