This comes from a good Journal, but reading it was a waste of time.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
This comes from a good Journal, but reading it was a waste of time.
You can say anything you want, but constructive, helpful comments are more important than personal comments.
The FCC doesn't make it easy to post your comment on this particular proceeding. Here is the link you need to follow. In the 'proceeding' text field at the top of the form, type the number '14-28.'
This pretended study is another one of those strange, invented approaches on an ongoing tragic issue... an angle that sounds intelligent on its face until you think about it for just two or three seconds. Then you realize how perfectly insulting this phoney approach to a real issue really is.
Go ahead -- tell the maids down at your local Best Western Motel that rich people work more than they do. Then drive a few blocks down to your nearest Home Depot parking lot. Tell those unemployed men waiting at the nearest corner hoping to find a casual, sub-minimum wage job from you, that they are on "recreational" time.
The editors of the Economist magazine ought to be horsewhipped for printing this story. SlashDot ought to be purple with shame for reprinting it. Seriously. I don't come here to read quasi-Libertarian krap like this.
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.
After writing about 90% of a thoughtful, detailed comment, your f**king comment software suddenly blinked my comment out of existence.
This is the number one reason why a commenter leaves a website. Number two: Oppressive over moderation. Number three: spam negligence.
I haven't got time now, so I'll get to the point: Don't change the font. White space is your enemy on slashdot. Bring back some curvy corners. GET RID of that awful floating menu bar. It feels like I have an eyelash in my eye. Respect your commenters: No one comes here for your home page. We come here to talk with each other about what we find on your home page. and FIX YOUR COMMENT SOFTWARE.
Cisco lost its vision as a company at least a decade ago. They are making most of the mistakes made by large companies with no business vision beyond meeting their financial projections. As a consequence, Cisco is slowly shrinking -- think General Motors in 2004 or so. In a few years, a larger company (maybe Chinese or Indian) will buy what's left of them.
I once met with a group of about a dozen Engineers -- all of them were excellent professional people. Their group had lost three supervisors in fifteen months and been transferred through two departments. Every one of them was concerned about their evaluation status -- they had had no real chance to contribute to Cisco in about eighteen months, and it did not have anything to do with their ability to perform. Each of these people knew he/she was going to hit the bottom of any layoff list that Cisco HR kept, because they had simply not been given anything productive to do for two years. This is what happens to good professional employees when a large company loses its vision, and it doesn't happen to just one small group: It will usually happen to hundreds of mismanaged professional and support groups at a time, all through a large company.
I am NOT convinced that this article is accurate. I don't think that Cisco has 80,000 domestic employees any more. Three years ago, they had two thirds of that number, and there have been layoffs since. Cisco also employs several times as many employees in India and China, as they employ here. Does this announced layoff also affect their overseas staff?
Cisco also relies on thousands of temporary employees to manage their workload. Are they going to send all their temporary employees home, before laying off, well; whomever they intend to layoff? If so, their layoff will be well over 10% of their workforce; not 5% -- and these percentages double if their domestic employee staff numbers only 50,000 or so.
The point is; that employers and banks aren't giving us a choice.
In the 1950s, San Jose and its suburbs adopted an urban growth strategy that was essentially no planning strategy at all. They minimized zoning and urban planning, assuming that giving developers the freedom to develop land without much oversight would somehow produce a quality urban environment as a side-effect.
So San Jose, Santa Clara, Sunnyvale, Campbell, Mountain View and Cupertino spread out because developers opted to build where land was cheap. However, city streets were not extended in a sensible way. To run personal errands on Saturday, we had to start driving five miles (and through a dozen stoplights) just to find a grocery store. Three or four other errands could require fifteen to twenty miles. Add traffic and stoplights, and it could take you five hours or more, to run just three local errands.
In addition, cities here allowed commercial property to mix a little too closely with residential property. This raised crime rates, lowered property values, and made everything ugly. No one planned for parks or shopping centers or other public amenities. When shopping centers were finally built, traffic patterns were ghastly. When planners were forced to route freeways through the area; they were routed where the land was cheap; not where they were really needed -- first they cut neighborhoods in half, and then in quarters. Parks were placed, twenty years late, where more land was cheap, or where well-to-do neighborhoods were still located.
All this turned the valley into a happy little piece of Houston, Texas, only with worse freeways.
The good things about Silicon Valley arose from areas that were planned: Stanford. Large Aerospace companies along Bayshore freeway. Aerospace died, but by then, silicon had taken the place of airplanes. Then silicon died. Today, we run on software and business momentum from the old days, but the momentum is formidable.
As bad as all this is, it won't ultimately kill the valley. I think lack of professional creativity and opportunity will finally kill us. Large companies here never did value what the Harvard Business School calls 'disruptive technology.' They do not hire creative problem solvers. Business startup costs used to be low: Today, they are through the roof, and getting higher. Venture Capital has ruled the roost since 1997 or so, they are getting stronger, and they do not value original ideas.
Major companies here are all slowly dying (like they always have -- remember Fairchild Instruments, DEC and Atari?) -- the difference is; that it is much, much harder to start a new company here than it used to be -- and new companies are where the big companies come from when the old companies finally die.
Google services usually experience an influx of popularity and income when first released. Over time, they gradually return a smaller fraction of their expenses. When a mature service begins to lose money, Management decides whether to update itor to kill it. Maybe a third of the time, management decides to kill it. It only takes a few decision cycles for an individual service and its number comes up.
Projects supporting services are kept loosely coupled. This works in Google's favor. This minimizes the effect that killing a service has on other services. When a service dies, most members are simply laid off -- even the good ones. The rest of the workforce seldom finds out. Over time, it is risky to work at Google.
Google is full of services that are on their way to dying, including Google Sites and Google Docs. Employees use these services internally, but they are woefully behind their competition and are becoming a productivity bottleneck. I believe they are close to being re-evaluated. With competing open source services like WordPress and LibreOffice, it might be easy for Google to just open source the code and reassign (or lay off) project employees.
Microsoft is also neglecting MS Word for similar reasons. MS Word is a bloated, mature app that doesn't make much money any more. It has collected lots of bugs that are expensive to fix. There isn't enough money to fix them. The new Ribbon UI has failed in the marketplace. It is bundled with an Office Suite that has its own problems. Some open source word processors are now better in many ways. Microsoft could have a Google surprise in store for 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.
Really. Buy some perspective.
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.