I say this as someone who loves variety in the newsreading experience: Good riddance.

But I did spend years working in a place where suit-and-tie was normal wear. We only took a few interns, and we could do without (and did without) rich kids who weren't interested in the job and couldn't be relied on, or who expected to be doing Important Stuff from day one and grumbled when asked to help with the chores.

What doesn't make sense is that the dress code makes a big deal about the distinction between suits, on the one hand, and sport-coat-and-slacks outfits on the other. Both of these fall squarely in the jacket-and-tie category of office monkey suits. Presenting sport coats as a more casual option, permissible on Sundays, is at least a generation out of date.

I love the "asking for a byline or questioning a byline decision is grounds for immediate termination" part of the contract.

I mean, I've got to have something to do on the bus, you know?

This level of specificity, and formality, is not uncommon in parts of the financial sector. E.g., the written dress code at my job specifies suit + tie as business formal, mandatory, except on Fridays when jacket + tie passes for "casual".

It would not surprise me at all to learn that the dress code at the Sun was copied from a brokerage firm.

In an awful* lot of corporations today it is a firing offense for an exempt (salaried) employee to tell another employee anything about his/her compensation: salary, bonuses, stock options, etc. This rule is intended to make it impossible for an employee to negotiate compensation effectively.

I personally think this practice is highly unethical (read: "evil") and should be illegal, but I wouldn't trust the courts these days to rule honestly in the whole area of employee relations.

* I mean that word literally; I find it awful, anyway.

The Fair Labor Standards Act requires that some tests be met.

First is salary; the employee can't be on hourly status. Second the salary has to meet a monetary threshold (and be in a job category which allows for exemption)

Third the employee has to have real supervisory function, over more than two people, have managment as a large part of the job function nad have responsibilties for scheduling, job description, hiring and firing, etc.

If that's not the case, the employee is slaried, non-exempt, and the employer owes them for OT, etc.

None of which has anything to do with the evil nature of the rules you're discussing.

This was (I assume it still is) a firing offense at the Container Store. As was discussing unions.

Ugh.

Union-busting deserves no pity.

(No affiliation with them whatsoever besides thinking they've got a good idea going.)

Actually, you also need to know the "step" the employee is at.

There are also differences depending on the employee's geographic location and a few remaining differences depending on job classification.

(Although all of this IS publicly available information.)

Third the employee has to have real supervisory function, over more than two people

Are you sure that's a strict requirement? I spent a lot of years as an engineer with no supervisory function, with several employers who kept calling me an exempt employee, and refusing to pay me overtime. They sometimes gave me comp time, but that was strictly up to my immediate supervisor.

I became an exempt engineer in 1978 at Intel, after working as an hourly technician for 2 years in the same department. The company had to increase my "yearly" salary by almost 25% to make up for the overtime I was routinely working*. That was the first time I came across the "telling someone how much you make will get you fired" policy.

* There's a scene in Tracy Kidder's Soul of a New Machine where someone in the R&D group that's developing the new computer finds a technician's paystub in the trash, and learns that, given 80 or 90 hour weeks, the tech is making more than twice as much as any of the engineers. To maintain morale, he burns the paystub.

Programmers get vastly overworked.

Some reasons:
* Time spent communicating between people seems to be on the order of N! . Therefore doubling the amount of people on a project does not double the amount of work that gets done, even if you hire them all at the start.

* Good programmers are hard to find and a good programmer can produce three times the results of an OK programmer. [Bad programmers can produce negative amounts of work.]

* Good programmers often think it's fun and don't MIND working through dinner.

* Programmers underestimate the amount of time they will take to do something by a factor of 2. I've heard this rule independently from several different sources, and verified it myself.

* Long hours, little sleep = bragging rights.

Result: you get a 60 hour "standard" workweek and during crunchtime people sleep under the desks. And then people make more mistakes because they're tired.

One attempted solution was CMMI, but there's got to be a better way...

* Many programmers are not designers; the skill sets aren't identical. Unfortunately, team composition and organization often doesn't reflect that. Lack of or poor design almost always means more work later in the cycle to fix problems.

* Many programmers are not good communicators. This can multiply the work to do at integration time, when programmers' code is put together and inconsistencies in interface and even in support of requirements becomes evident.

* "We don't need no steenking unit testing!"