The summary is very careful to describe the lowest performing workers as: Every team has someone who at the bottom of its bell curve: an individual who has a hard time keeping up with other team members. Based on this definition, as you replace one, you will still have the lowest performer. Just your measure criteria will be higher. Thus unless you have a team that are all clones of each other, work politics will still find the "idiot" to hold.

Yes, obviously someone else will take over the bottom spot. But remember that a bell curve has an important parameter: variance. Your "all clones" team has a variance of zero. Replacing the low performer with someone closer to the mean will not only raise the mean, it will also lower the variance.

Thus, the measure still stands: How do you treat your lowest performers is a good judgement of the company health. Your preference of "Not worth the time/effort. Replace them with someone better." is quite destructive. By following your solution, the team will be forever stuck with overhead of training up the new guy and loss of knowledge of the rapid turnover.

First of all, what I outlined in my post is by no means meant to be a "solution", much less "mine". Second of all, your rapid turnover conclusion is based on flawed premises. If you replace the lowest performer with a new guy who ends up at the very top of the bell curve, and manage to do that repeatedly, that is unlikely in itself. You're far more likely to find someone who will slightly raise your mean performance, but mostly reduce its variance, making the "next idiot in line" less likely to be as much of a problem as the last one. Also, being "forever stuck", as you state it, would imply that there is some magical, unlimited source of "better people" allowing us to keep raising the performance ad infinitum. Which is obviously not the case.

The real message here is: A large variance in your team's performance is a problem. If your team/project happens to be successful, for whatever reason, you will be able to tolerate a larger variance. But I would argue that the best team is one that performs consistently well, i.e. one with a high mean and a low variance; and in general any team with a low variance will have a better chance of performing well than a team with a higher variance.

There are cases to be made for the advantages and efficiencies of all approaches, but, generally, you need to be a strong development team to carry and build up the weaker team members - if everybody is too focused on product and producing to care about helping their fellow team members to improve, your team is overtaxed (too weak for the job at hand) and probably not able to perform well (provide a reliable living wage for the developers while producing and maintaining the product) in the long term.

Yeah, I think that is the important -- and only -- message here. From the summary:

How your team members treat that person is a significant indicator of your organization's health

This, and only this. If your organization is doing well on the market, and very successful, it can afford to treat their "idiots" well. If times are rough, and everybody is struggling hard to get things done and achieve success, this will stop. In other words, if you're treating your "idiots" badly, it's probably because you're already in deep shit.

However, the converse is not necessarily true: it does not follow that just because you're nice to your "idiots", your team will be successful. Sadly, as much as I'd like to interpret such a feel-good message into TFA, I'm afraid it probably doesn't work that way.

My personal experience seems to indicate that yes, you do want to treat your "idiots" well simply because everybody likes a good work climate, and nobody likes assholes. And personally I'd rather not do as well but at least know that I'm not acting like an asshole trying to beat the team into performing better. But in the end, what motivation and performance you can instil in your "idiots" is unlikely to match what you could achieve by replacing them with individuals that are more capable of doing the required work.

I get that, I work with 3D point clouds and stereo and RGBD sensors every day.

I get that too. That is the idea and the claim, anyway. The point of my post was: The video posted with the ScienceMag article does not prove that this is what happens! The task shown could have been accomplished by memorizing the sounds and the descriptions given by the interviewer. That's still fairly impressive. But from the video, we do not know whether the participant actually does what the authors, and you, say he does – namely, actually recognizing and understanding the picture. As I said, the video is worthless.

In different terms, what the video shows is that the participant reproduces the classification on the training data. What's missing is the test data that the participant didn't use during training.

As I don't have access to the full article, I would like to know if anyone could tell us about whether the conclusion is at least supported from the actual data presented in the paper. It definitely is not supported from the video.

Except that video doesn't prove anything of that sort. It merely shows that the participant has learned to recognize specific sound patterns. For all we know from the video, he may have been told the following:

• First sound pattern playing
• Interviewer: This is John. He is bald and has black eyes and a goatee.
• Second sound pattern playing
• Interviewer: This is Lisa. ...
• ...

...as a result of which, the participant is able to recognize the pattern and recite what he has learned.

If they wanted to demonstrate that the participant could really recognize the faces from the sound patterns, they should have presented him with a face he hadn't seen/heard before (i.e. didn't know the name of the "person"), and asked him to describe what he "saw".

Anyone with access to the Science article, did they at least report such findings in the actual paper? Because the video is worthless.

2) White space and wasted space. Enough have made detailed complaints about this, so I'll just register my chagrin. I will say this: the people who come to this site are used to, indeed prefer, a denser presentation of information. This includes the text editor, which is absurdly restrictive on the x-axis.

I'd also like to fully concur on the white space problem. This (1920x1080 screen, standard zoom level) says it all in my opinion. The actual percentage of screen real estate containing the useful information that people want to see, on the front page, is about 22%.

Mind you, the "classic" front page is not that much better, but at least it weighs in at about 30% -- and the surrounding stuff (sidebar etc.) also uses its part of the screen real estate much better.

Up front, let me say thanks for joining the discussion with us here. It's definitely appreciated.

Well, those few needed tweaks never stop piling up. On top of that, UX research and (more importantly) user expectations continue to evolve.

[citation needed]. Yes, UX research evolves. But could you please point out some concrete examples of where UX research has brought out new insights that you think Slashdot needs to integrate into their site? Also, please provide some details on these user expectations that you have learned about which led you to the conclusion that the new design was necessary. What were some concrete aspects in which the old site did not meet the users' expectations? Who are these users? Are we talking about user expectations of some "general public" or of those users currently using the site and making it what it is? Please clarify.

To keep up with that, websites either need to constantly change in small increments, or to do it in big chunks. We'd been doing the former for a while, but the decision was made to start fresh. I totally understand how jarring it is to see such a huge amount of change all at once, but we also have to look at what the website will look like a few years down the road.

If the premise holds (if!), then I am willing to follow your conclusion. But I don't think this is really about big chunks vs. small increments. In both cases, the changes incurred should have a justification and rationale behind it. And it seems that a significant part of your userbase (myself included) either does not understand your rationale, doubts your justification or simply has no idea about what your concrete justification and rationale is. And as others have pointed out on here, it's not the articles that make Slashdot the great site it is, it's the comments. In other words, your userbase is not an audience, and I don't think they deserve to be called that. The articles are the seed. The conversation, and the Slashdot community, are what make the site great. If there is an audience, it's for the most part our audience (or at least it's the audience of those posting here more regularly than myself).

The classic design in 2014? Not too bad. The classic design in 2018? Probably not going to cut it.

Again, [citation needed]. Now, I don't want to be a proponent of complete stagnation. In fact, there are a number of things that I think could use improvement. But please be more specific: How is the classic design not going to cut it?

My personal opinion on what Slashdot needs to improve in general, in the Beta (if it is to survive) in particular, and in communication with its userbase as the Beta progresses:

• Unicode. I think this is way overdue.
• I don't have a problem with the general idea of a new design. In fact I'm all for a design that suits the larger variety of different screens you have to cope with now. But as many others have said, don't waste my screen space. I want to see a compact design that allows me to gather information from not just a single comment, but as much context as possible.
• You pointed out yourself that the comment system isn't quite there yet. I completely support the sentiment that the comment system is the heart and soul of your website. If it isn't quite there, Slashdot isn't quite there, and in my eyes a beta is pointless as long as the comment system is in such a horrendous, unusable state.
• How about you keep us up to date about what your general aim is with the new design; what concrete features are still in planning, currently progressing, or finished; what conclusions you drew from user feedback and what actions you took as a result of them?
• How about, more in particular, you keep giving us feedback on our feedback, so people know what you think of their feedback, and so they actually get the impression that you are listening?

That said, I hope you take all the feedback seriously, and while I personally don't really need a new, fresh design, I do hope that since this is what you seem to want, you end up with one that is the result of actually listening to your community, and can be considered an overall improvement.

(nearly) Every computer has a video device which has a loop running over the frame buffer, outputting pixels to the display output port.

Yes, but there are a lot of video device manufacturers out there. When we talk about the most often run piece of code, do we mean "all implementations of code that do the same thing", or do we really mean "one specific implementation"? I would opt for the latter - which means you can't consider all desktop machines out there, only all those with video devices that really use different incantations of the same code. That lower the number quite significantly.

Even earlier, IEEE Spectrum had an article about KIVA as early as 2007, and a more in-depth one following in 2008. Amazon bought KIVA last year (even Slashdot noticed) for obvious reasons -- workers get a new item to pack into a box about every 6 seconds. The whole AGV system is highly efficient, significantly speeding up the warehouse processes.

I'm quite surprised Slashdot didn't pick it up back then -- but then again, I suppose I could've posted it when I first read about it :)

People are frightened by what they can't control, can't predict, and don't understand.

I love how most people commenting on this article write only about they, them et cetera, conveniently leaving out themselves.

At least, be honest and write we and us instead...

It's not you wasting food. It's the restaurant wasting food by giving people unreasonably large portions. Blame them.