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).
Does a docking station really offer so much more?
It depends on the particular situation. If you have a lot of devices, multiple monitor setups, etc. then yes. Using a docking station, you simply sit the laptop on the dock and push down slightly (or close it and slide it in, depending on the laptop) and you're good to go. Otherwise, you have to connect a power cord, monitor cord(s), any USB devices you may be using, speaker connections, eSATA ports, etc. If you only have an external monitor, or a printer, or something where you're only talking power and a couple cords, it's not so bad without a dock. But even with that, it's still more convenient to simply have to deal with sitting the laptop in the dock than to try and get the video cable turned the right direction and aligned with the pins before you can get to work. Plus, some docks (like the Dell D series) can be mounted on notebook and monitor stands, giving you added benefit of a better viewing angle or a convenient storage spot while the book is docked. At least for me, it wouldn't necessarily be a deal breaker, as MacBooks are really nice systems, and I can live without a dock, but it really depends on your workflow.
You point out an interesting problem that many call centers face though. There isn't always a perfect correlation between the number of calls a given agent takes vs. his ability to service the customer. If he is manning a queue that is responsible for first-level or tier 1 support, his job may be quite simple, requiring him to do some very basic troubleshooting in an effort to appropriately route or escalate the customer's issue, while solving the very basic or simple problems so that the other departments have more time to troubleshoot more detailed issues. In that case, he will take a higher number of calls than agents in other queues simply because the nature of his calls means they will be shorter, but he can still effectively service the customer at the same time.
Even in longer staffed queues, an experienced agent may take more calls because he is able to resolve issues quicker than a newer agent in the same queue, and quite possibly provide the customer with a better experience than they would have had with a different agent. On the same token, someone who takes fewer, longer calls in a queue that typically sees quick, short calls may catch the eyes of management because of their metrics, but they may be a better agent who spends a couple of extra minutes per call ensuring that an issue is resolved, and preventing additional calls for the customer. Yet they will probably be fired/laid off purely because of their metrics, although the metrics don't accurately reflect their ability to service the customer.
It's because of things like this that management often incorrectly bases their decisions off of incorrect or incomplete data, because they simply draw incorrect conclusions or don't take a deep enough look at an employee to find out why their metrics differ from the baseline that they have (often arbitrarily) set. And it's not just limited to call centers. I've seen managers do the same thing for developers, attempting to judge what kind of employee they are purely based on superficial things like how many lines of code they produce or how many SVN commits they do, instead of judging them by the actual quality of their work.
Things like serious attention to detail, efficient production of code, and being able to quickly and easily resolve complex problems in a few lines of code or a few commits is MUCH more important than writing lines and lines of redundant code or recommitting your project 10 times before you finally get it right. Problem is, the best way to measure that is to have someone managing you who actually understands what you are doing, and that sadly just doesn't happen as often as it needs to.
Yup, I've been there, done that
You can't fire a developer that's leading in resolutions and completed requirements. It's that simple
Sure you can. If you have any measure of intelligence or ethics, you shouldn't... but you can.
I was laid off from a job after working there for five years, having completely rewritten most of our code from scratch, and ultimately being the *only* person in the company who knew how to interface with the various systems we had to generate reports and performance metrics for both of the company's call centers.
My final months there, I worked my ass off (often working overnight shifts) generating custom reports that my manager requested at the last minute, so that he could provide data to the CEO, often times giving me 15 minutes notice that he needed some outlandish custom data for a meeting. With the short notice, it wasn't uncommon for the manager to get his ass chewed for not having provided the data ahead of the meeting and for not being able to give any additional details (since he had no clue what was going on with the department outside of the data I had to provide to him).
So when the time came to make cuts, my manager decided to pass on the blame and selected me, claiming that I didn't do anything. Pretty much everyone else there knew differently, since they actually worked with me daily on different projects, but because senior management was under the impression that the manager was providing the data himself, they didn't question the claims against me. And since it was a layoff instead of termination, I really had no recourse anyways.
Or if he knew that employee spent time trying to cover his or her own ass instead of -- you know -- just get work done?
I have to agree with the article on the point of keeping documentation. It's a good idea, though you shouldn't be spending more time doing that than doing actual work. But if you find yourself in a situation like mine, where they choose to mask it as a layoff instead, all the documentation in the world will probably not help you much. I could have easily proved what I did, but luckily I didn't have to, since they soon found out once I was gone and the manager wasn't able to come up with the data he needed, and got himself fired just a couple weeks later.
By that time, I had found out the actual reasons behind my termination (since I was initially told it was just a routine layoff) and had heard what had happened after I left, but the company chose not to hire me back citing pay as the reason, just like ducomputergeek commented.
Time after time, we have seen apps rejected for content that the app simply links to or obtains from the Internet, and it appears that the reviewers do not understand this... they seem to believe that the "inappropriate content" that they are obtaining is actually an inherent part of the application, and therefore reject it.
As has been stated before, I also think that Apple simply puts forth base guidelines for the reviewers to follow, and leaves it up to their discretionary tastes beyond that. At some point, someone higher up at Apple needs to take accountability for this and ensure that the process is redefined, across the board. And it would be in Apple's best interest for that to happen sooner than later, or they will soon find that other solutions will be much more attractive to developers because everyone else has their act together.
Laser pointers getting aimed at people's faces are bad enough, but this is like having 3 lasers waved around wildly.
A good number of projectors are used to display a screen to a large audience, while a presenter stands in front of it. For the presenter, getting the light in the eye is nearly unavoidable. So with lasers, you're talking serious eye damage if you're in the way.
Every single graphical trick done to either speed up or sexify your web site is done with tables inside tables inside tables--it's tables all the way down!
Apparently, you've never visited the Zen Garden.
With Apple being Apple, I think if they ever do venture down that road again, it will be because they have come up with a new and different method of licensing the software.
However, it's pretty unlikely IMO, given that Apple likes to maintain a very specific user 'experience', and allowing their OS to be used on potentially sub-standard hardware could undermine that experience and potentially turn some away from the OS.
This comment is worded exactly as intended. Any application of lame "Fixed that for you" jokes will be "dealt with".
Fixed that for you. Sorry, couldn't help it.
Anyways, I agree... DVD and flash options have a very different use to many. I'm not going to go buy a pile of 4 GB flash drives and use them to backup my content, then stick them in a safe. I'll use a stack of DVDs for that. I also use DVDs for large installation files that I want to keep a copy of.
Flash drives are great for point-to-point copying and then deleting when you're done. No need to make a coaster. Plus they work in any computer with a USB port, where DVDs only work in DVD drives, and then only ones that can read the correct format (-R, +R, DL, etc).
I can't say I agree with the suggestion of assigning a reviewer to a developer though, as that opens a few issues. Take the NIN case for example... what happens if you get a reviewer that hates NIN's music style and only listens to classical and light jazz music? They will inherently be more likely to find the NIN apps objectionable, albeit by their own standards rather than Apple's. Sure, now Trent's apps get rejected consistently, but the process is not any more fair or equal than it was before.
I think there needs to be a clear set of guidelines that their reviewers need to follow, as well as a similar (if not the same) set of guidelines published for developers to follow. I can see some justifiable reasons why Apple may not want to publish *everything* that would be rejected, because some items may require a more subjective look or may have extenuating circumstances. But at least a clear set of guidelines would help to clear the air. Then, if an app falls into a grey area, where something needs further review, two things should happen:
- The developer should be notified that their application is being processed, and that it needs further review for X reason, and
- The application is then sent to a smaller, more specialized committee to determine the exact nature of the issue and whether or not that violates the policies.
Then, if the application is rejected after that, the developer needs to be given a very specific and detailed response as to why the app is rejected, and what (if anything) they can do to correct the problem. If necessary, this could be under the NDA (that the dev has already agreed to) so that they could disclose the reasons to the developer without restriction.
Either way, the decision and details should be fully documented so that any future questions could be answered. That way, if app A has been approved, and similar app B is rejected, then a dispute resolution could review the reasoning used in both decisions and determine a more fair resolution. Just my 5 cents