jhferris3
Joined 16 years ago
Joined 16 years ago
Another thing to note in his section with self driving cars: the pool of cars would be fixed in that case, but the amount of uber drivers fluctuates throughout the day. Now, uber doesn't really care if drivers are 70% utilized or 50% utilized, as their revenue doesn't depend on that, but they do have an interest in keeping the drivers marginally satisfied
Also I don't have the numbers but at least in SF, taking an uber to the airport is much cheaper than taking a cab ($25 vs 50 from my office, last I checked), so I could imagine that something like that skews the distribution of ride lengths.
http://www.scientificamerican.com/article.cfm?id=depressions...
Should somebody try to do some smart parsing of failure notifications to make them more readable? Sure, I don't see why not. But don't pitch the baby out with the bathwater here. The underlying system is not that bad.
In all likelihood, there's no magic. Its just comparing 'dumb' manual album labels with places pages and trying to match them up.
I've had similar experiences with the location-suggestion feature where I was totally bewildered by how it was getting the data to recognize the locations. As it turns out, all of the albums they've done this for were pre-location tagging and so I'd manually put in a location (like 'Bowery Ballroom'). So there wasn't any particular magic in how they seem to be doing it. This would also explain one of the other comments on here about the location suggestions being England, Arkansas (if she just labeled the album England and the location suggester goofed). I also had it goof when I had an album labeled "Rhode Island and Massachusetts" and it tried to suggest a real estate agency with that in its name.
One of the other annoyances we had (I think its addressed in the note?) is that until now the interpreter (on our dev machines) and the compiler (hphpc in production) occasionally differ in small, occasionally painful ways. Unifying our development and production environments will eliminate another potential source of bugs.
Also: Tight loops don't imply a lack of understanding. Often times when you're trying to get the CSS on a page just right (across all browsers) it requires quick iteration, even if you do understand CSS well.
That said, I'd like to think that most people/kids under the age of 20 or so have much better grasps on a computers technical specs, at least comparable to how most people are familiar with the relevant specifications on a car (HP, torque, fuel efficiency, etc)
The difference between 4gb and 8gb of ram? Huge difference (even if you aren't running memory hog programs, the OS uses it for prefetch)
How about ssd vs rotational disk? Anyone who's had an ssd as their boot drive will tell you, it makes a radical difference.
So no, its not like a hammer at all.
What the hell? Beyond the fact that this is one small part of a book (not the same as him saying it on video or written by himself on a website), there's no way the average joe is going to have his purchasing decision swayed by the opinions of Steve Jobs. Everyone who would already has (or is planning on procuring) an iPhone.
WHAT IS THE PROOF! (also known as 'consider the author', 'read the article', etc)
Now I can't say with certainty that any of these claims are false or true, but it occurs to me that a lot of these claims are based on what facebook MIGHT be doing with your data. I decided to take a look at the complaint and attachments for the shadow profiles case, I don't see any evidence that these shadow profiles exist, just that there is the possibility that they exist.
And for those that will inevitably say that proof isn't necessary, that means you don't trust facebook. If thats the case, there is nothing they can do to prove to you what they're doing is legitimate short of open sourcing their entire stack (and even then, you must trust that what they're running == the source they give you). So either trust that what they're saying is true, find evidence that they're doing something they aren't supposed to, or stop using the service entirely.
Everyone has a cognitive limit on what they can keep track of/in working memory. Once your codebase exceeds that limit (in # of files, lines of codes, types, interfaces, etc.) you lose productivity. 10k lines of python is a lot harder to grasp than 10k lines of go.
And that's not even considering the ramp up time for someone new to the code to jump in, which is even worse in most dynamic language codebases.