Yeah, but they didn't just skip version 9. According to Microsoft's internal versioning scheme for Windows, Windows 8.1 is actually v6.3. Microsoft decided to skip 6.4, 7, 8, and 9.

So no, this is unlikely to be the result of anything other than Microsoft finally saying, "Let's have our internal versioning scheme match the marketing versioning scheme, and just make all references to Windows show 'version 10'."

In that sense, I think it's also about setting realistic expectations. With almost anything you want to do, there's some limit to how fast it can be done, even with unlimited resources. Limiting the resources available below the optimal level will increase the amount of time to accomplish things. So you can't take a project that will take 6 months to complete, cut the resources to keep the budget low, and then set a project schedule for 3 months and expect it to work.

After a certain point, providing big bonuses doesn't make things happen faster. It just encourages people to cut corners to meet the technical requirements for the bonus, even if it means providing a useless end-product at the end of it all.

First, that doesn't seem to be what the article is saying. Second, I don't really believe that it's true.

When I say "don't believe that it's true", I'm saying, "I don't believe that the removal of managers necessarily gets work done faster." I'm not talking about programming specifically-- I'm not a programmer, and managing programmers is not my expertise-- by my general experience is that a lot of people think managers are just wasting everyone's time, when the reality is more that most people don't understand what managers do. Unfortunately, this sometimes includes managers.

A good manager often spends his day trying to figure out how to remove obstacles so that the people he's managing can just do their jobs. For example, the summary says, "The article encourages managers to let devs contribute to the process and say 'No' if the specs are too vague." That sounds right to me. First, a good manager will of course listen to the people he's managing. That doesn't mean doing whatever they say, but when I have managed programmers, I assume that they know what they're doing better than I do, so if they say there's a problem of some sort, there's a problem of some sort. I wouldn't always go with their recommended solution, but would I listen to their explanation of the problem and try to come to a solution that addressed the programmers complaint as well as meeting the business needs we were trying to address.

If specs are too vague, that seems like the sort of thing a good manager would help to work out. For example, I might suggest talking to the programmer, trying to figure out which aspect of the specs are too vague, and then meeting with the stakeholders to try to clarify the specs. I wouldn't necessarily make the developer get involved in the process of clarifying them, since unless they're needed for the discussion, they probably have better things to do.

But being a good manager is pretty difficult in general. It's often not clear what needs to be done, or how it ought to be done, and it's your job to figure that out. It's pretty much impossible to be a bad manager without annoying people, but even the best managers might seem annoying or clueless because you don't see what they're doing for you. Sometimes good managers are only noticeable in their absence-- when they go away, you suddenly go "Oh jeeze, things are falling apart a bit here. How was it that we never had these problems before?" And the answer is, you were having those problems, but your manager was dealing with them when you weren't paying attention.

Maybe I'm just in a bad mood and being an asshole, but I can't quite wrap my head around this post. "Hi everyone, I'm a random anonymous person on the Internet. For reasons I won't explain, I've decided I don't like Linux, and I want to try BSD. My needs are that I really want to play 3 specific games and run Firefox." I'm not even seeing where he actually asks a question, but timothy wants to know how Mr. Anonymous can fix his undisclosed Linux problems by moving to BSD.

Well, let's see. First, since you're apparently just running games, who cares what OS you're using? Does your current OS play those games? If yes, keep it. If not, look to see what operating system supports those games, and choose one of those operating systems to try out. Firefox and some kind of view player? I don't think that'll be much of a problem. Somehow the issue of hardware support isn't raised.

You know what? Use PC-BSD. AFIAK, it's basically the only BSD distribution, aside from Mac OSX, that's specifically targeting desktop use. Or maybe, since you only need a web browser and a couple of games, you should use whatever OS runs those games and stop worrying about it.

It should be either "products that are unstable" or "products that are not stable". My point there is, you can make lots of iterative improvements on Google Plus because it's software that can be changed after deployment, and if you screw it up and have a small disaster, who cares? People are briefly without their social network while you fix the problem or restore from a backup, or whatever. A lot of things aren't like that. Not all software engineering concepts are universally applicable.

I don't think it's really off topic. When I read, "What did it mean that one of the world's most ambitious and capable innovation companies couldn't invent a cheap renewable energy tech?" my first thought was, "It probably means that inventing cheap renewable energy is difficult, if not beyond our current technology, if not impossible. What, did these Google engineers really believe that the only reason it hasn't been done yet is that everyone else is stupid?"

There's definitely something a bit silly about startup culture, where there's an assumption that software and fresh ideas provide the solution to everything, as though all problems in life can be solved by a cleverly designed mobile app. There's also a sort of assumption that the skills involved with programming are the most important and most useful skills possible, and are applicable everywhere. I've heard arguments that programming methodology should be applied to all fields-- medicine, engineering, government, everything-- while somehow failing to recognize that the results of those methods are products that are often not unstable, both in the sense of "ever changing" and in the sense of "crashes a lot".

I've met a bunch of Google employees over the years as well as other startup-y tech companies, and the general trend seems to be that they're nice people, and they may be very good at what they do, but they overestimate the importance and universal applicability of what they do.

That said, the functionality that I've been hoping for pretty much since I heard about Bittorrent Sync is the ability to use this as a sort of distributed file system with a desired level of redundancy. So, for example, it be great if I could buy a bunch of consumer-level NAS devices with a few terabytes each, stash them in various places (friends and family's houses, wherever), and say, "I want every unit of information to be stored on at least 4 of the devices". Not necessarily 4, but however redundant you'd like it to be, based on your need for reliability and the reliability of your individual nodes.

If you could do that, then you could build your own scalable, redundant, reliable, fast Dropbox replacement on your own hardware without a single point of failure.

Yes, the "cloud" servers sometimes have outages. So do managed hosting providers. So do internal servers. And frankly, although every business thinks that what they're doing is super-important and they can't afford even the briefest outage, the fact is that most businesses can.

If Azure or AWS go down for an hour, it makes news and everyone freaks out because a lot of people are using them. If your business's server goes down for an hour, it does not make news, and people don't freak out. But for the business experiencing that 1 hour of downtime, what difference does it make whether they own the hardware or it's in "the cloud".

I'm not an expert, but there is some part of your brain that specifically interprets faces. Maybe the information reached that part of the brain, but couldn't be processed beyond that.

Probably because, although you might think of Slashdot as a bastion of intellectuals and scientists, it's really a pop-culture news aggregation with nerd-centric marketing. Most people just want a summary, and don't want to read the actual paper.

And honestly, I'm in the camp that doesn't necessarily want to read the paper. I do recognize that there's a problem with journalists oversimplifying and mischaracterizing scientific ideas, but scientific papers are often written with the idea that you're versed in the particulars of the field being studied. I'd generally prefer to get the layman's explanation, and then dig into it more if I want to.

It seems like the best approach might be to include links to both the lay press summary and the actual papers.

Yeah, I was thinking about that. Like... I bet somewhere in that span of time, someone must have noticed this bundle and asked, "So what is this?" and someone else looked at a text book and said, "Oh, it must not be anything, really. It's not in the book. If it were anything important, it would be in the book." I wonder how many times that happened, and the people involved just moved along and forgot about the whole thing.

Now a doctor may correct me, and give good reasons why this wouldn't be noticeable in most circumstances. However, I like the idea of something like this being discovered as a lesson about how science historically works sometimes. Everyone has an idealized notion of science that it's just constant progress, and that things are all already known and analyzed, and the only things left to discover are very hard questions like, "what is the smallest fundamental particle, and how big a particle accelerator do we need to observe it?"

But you know, science moves forward through the effort of people, and people aren't perfect. Sometimes something gets lost. Sometimes something important gets disregarded. Sometimes science moves forward because someone isn't afraid of looking stupid, is willing to admit what he doesn't know, and says, "Hey, what is this?"