This comes from a good Journal, but reading it was a waste of time.
This is not a well-constructed quiz. The problem, is that the poll doesn't recognize temporary employees.
Normally, I wouldn't bother commenting. It's a quiz, and who cares about temp employees, anyway?
... but this is an example of a significant blindspot for Slashdot employees. Apparently, you guys don't realize that companies like Google, Apple, Cisco, Facebook, Microsoft, Yahoo, Oracle (and others) hire a significant portion of temp employees to do their real day to day work. They hire only the few people they need, to supervise the temps they retain. Temporary employees have larger, and very different problems than this quiz implies.
Is this important to SlashDot? I'd say so. I think you should have a feature every day, that reports on something involving temporary workers. There are a Hell of a lot of us.
I hate this policy, of selling our public bandwidth to private corporations. I just hate it.
Airwaves are public. The Government should not be selling property that belongs to all of us. Leasing or licensing bandwidth for some specific period of time is one thing, but transferring ownership is another. We should not "privatize" this.
I am dismayed to see so many politicians and technical types just accepting actions like this, without any policy discussions taking place -- beyond closed-door meetings at the FCC, which are not shared with the public.
NOTE: I have no friggin' idea why; but the
Technical documentation is bad because very few software projects identify documentation as a task they need to accomplish, in their Project Plan. Marketing does very little in their PRD. Engineering does next-to-nothing in their FS.
When it finally does occur to the Project Manager that customers will need something, the engineers on the team think that it's a piece of cake. They already have an Engineering Specification; surely customer documentation can be easily extracted from the Project Spec -- the technical team can just 'wing' it the last month of the project, and everything will be fine.
... so the project deadline approaches. The spec has become grossly incomplete and out of date. The Engineering team has no idea who the buyers will be. Engineers generally lack the writing skills they need, to prepare long, detailed documents. They haven't defined anything; outlined anything; identified questions that users would ask. The Marketing team (involved by this time) doesn't really know how to write, either -- but they think they do; and they also think that usual Marketing bluster will get them by.
So things go wrong. Engineering and Marketing get in a fight, which wastes time. Sensing doom, the first few Marketing people leave the project. As a compromise, the Project Manager forces the Lead Engineer to assign someone on his team to document the product. The Lead Engineer assigns the most junior Engineers on the team. They fail to produce anything usable, because the Lead Engineer has also placed documentation last on their list of project priorities.
By this time, the Project Manager realizes he/she has a serious problem. To calm everybody down, he/she hires a technical writer at the last minute. He treats the writer pretty much as a secretary: No technical briefing. Not integrated onto the team. The Engineering Lead has placed the doc files under Engineering version control, where every misplaced semicolon in a doc file unnecessarily breaks the nightly build.
The Project Manager still expects the documentation to be finished on the same minute of the same hour of the same day that the product is released as an alpha/beta/PR -- sometimes a few weeks early, so it can theoretically go through QA first.
Through all this, no one (except the writer) has thought to ask what the customers (including the technical customers) actually need to know.
It always ends badly for everybody -- because the Project Manager and his initial team ignored their documentation requirement because it didn't look like it would cost enough to require their management time.
While Microsoft deserves some criticism; other large companies are worse (and more cynical about it).
Open Source projects generally handle Documentation worse than this.
Blinding speed can compensate for a lot of deficiencies. -- David Nichols