Even without working for Google, I can fully appreciate most of the issues and proposed solutions. Like in any big company, only the people "deep in the trenches" even see these issues, worry about them, and worry why management is so clueless that they don't even see the issue.
However, the key is to understand that these are simply superficial manifestations of a bigger issue: as the company grows in size, communication requirements grow exponentially, and even a slight mismatch in the talents of people will lead to serious issues. I don't think any of the recommendations will work at the scale of 20,000 engineers that Google has.
Take open source software for instance. For a 10 person start up, it works beautifully. Now try convincing 10 other startups to adopt exactly the same set of software, and you'll have a never ending religious war on hand. But you cannot also let everyone to pick their own solution, for then the 10 different groups cannot integrate with each other.
Far too many people keep complaining (I complain where I work for as well :), but the solution is not easy. By far the best approach is for people to realize that there is a need for a company to grow so much, and not anymore. However, human nature will not permit that.
Another way of saying the same thing is that GAE is perfectly fine if you know all the requirements of your app before you build it. In a perfect world, you know exactly what you want to build, everything you want is available with GAE, then you go build it and it scales nicely.
In the real world however, requirements change:
* You come up with a new idea that requires a certain library. Chances are, the library won't work on GAE out of the box.
* You find out that you need to change your schema. It is pretty hard to update to the new schema while keeping everything in sync.
Finally, you pay the Google cost. When Google implements a new feature, they spend enormous time making sure that it scales well. They need to do so since they could be looking at millions of users on day 1. Most of us however, are looking to build something as cheap as we can, not knowing whether anyone is going to bother to look at it. However, you have to do the same performance optimizations that Google has to do so that your app scales. Chances are, it will be wasted effort - unless your objective is to just learn. I find it funny that GAE goes completely against the rule that "Premature Optimization is the root of all evil". Yes, you should think about your application's scalability. But your bigger problem should be about finding traction, and being able to react fast, not optimize for millions of views.
If I understand correctly then, it would appear that GAE may be poor for applications that require heavy computation on the server side (say, a facebook style graph, crawling and computing various metrics on it) but great for serving tons of dynamic pages?
This is a beautiful piece of work. Any chance you might be able to explain the background architecture that might allow others to replicate some of this?
From what I see:
- extensions are coded in Python, and there is good documentation on the plugin mechanism.
- Each platform seems to use the platform's native window system. There is no use of a common UI like Qt.
- The first version is GPU accelerated but the newer one is entirely software.
Seriously impressive work considering it is a single developer. I like how there animations are subtle, and how the entire UI is incredibly responsive. To me, this does to text editors what Chrome did to web browsers.
The situation is no different than with laptops. You can expect certain quality standards out of Macbook's. You might be able to get something far cheaper, with more features from others, but there is clearly a market for Macbooks..
I don't know if users of Android care whether Android is open or not. Now there will always be geeks who will run nothing by Linux or *BSD, but most others don't care.
This post has to be taken in context of everything else that Piaw has been saying for a while: Google is an excellent place to work. It may not be as nimble as it used to be, but it is still better than most other big companies and most other startups as well. Sure, it is not _the_ best place, but it is right there at the top.
Once you keep that as the background for the article, then you realize that the article is meant for Nooglers interested in a certain career path. It is not for everyone, but it is certainly the most common expected path for the majority of their engineers.
It is odd to see HN jumping to conclusion reading one article without any background. I think thats part of the reason why bloggers stop blogging because whatever they say is taken to mean something else.
That is very true. Google's interests are very simple to fathom: They want more people on the internet. Anything that helps (in this case making it easier to develop internet oriented products) towards that is a worthy product to develop.
Sorry for this OT question, but does anyone know of a replacement for Omnisio (http://www.omnisio.com/)? They had great integration of slides and video and how you could browse to a particular slide.
Another Google acquisition that hasn't seen the light yet.
"Born to Run" has popularized this notion that the human body evolved to run long distances. However, there is no strong proof for it. The recent discoveries from the Ardipithecus (http://en.wikipedia.org/wiki/Ardipithecus) stories suggest that "both A. kadabba and A. ramidus lived in "a mosaic of woodland and grasslands with lakes, swamps and springs nearby," but further research is needed to determine which habitat Ardipithecus at Gona preferred".
When it comes to evolution, I don't think a popular book can provide all the answers. I wish they'd make it clear that this is just one theory now widely popularized by a best selling book.
It's also important to make a distinction between "the human body evolved to run long distances" and "the human body is well-suited to running and doing it for long distances is good for you". The latter seems like something we can (and should try to) prove now, without relying on the past for evidence. Knowing how our ancestors lived is nice but I'm personally more interested in knowing what's good for me, here, now.
If I recall correctly, Ardi had an opposable big toe and although he was bipedial, he couldn't have walked or run like us. If "Born to Run" is correct then Ardi represents a point in our lineage after bipediality developed, but before we evolved to become runners.
Curious if you've read the book (I haven't) and why you think that an entire tribe of people where 70 year old men regularly run 30-50 miles is not "proof" in your eyes?
Yes, I've read the book, and I would recommend it. The book makes multiple claims: The first is that given the proper environment (physical & mental fitness), we can run very long distances. This I think it proves very well with the Tarahumara tribe example.
It then goes on to make the claim that humans evolved to run long distances, in order to do persistence hunting. Persistence hunting is basically outrunning an animal for long distances so that it just drops down because it is tired. While persistence hunting itself exists, it is a stretch to say that this is how humans evolved.
The Ardi discovery that made news a few months ago shows that Ardi's environment was not really the savannah, but something that had far more trees. Persistence hunting requires a savannah like environment.
In the end, all I'm saying is that it is ok to say that humans can run long distances, but saying humans evolved to do that is far trickier and requires a lot more proof. The scientists involved in the Ardi discovery do not make any claims at all (after 15 years of studying fossils in one region). They are far more humble, and say that many different scenarios are possible.
Popular book writers on the other hand have to explain things to a lay audience, and usually provide one point of view (which typically fits their own mental model). Confirmation bias is usually rampant.
There is a difference in stride efficiency between jogging and running at high speed. 20 year old men don't run 50 miles in one go let alone 70 year old men. Now jogging that distance over several hours is a reasonable form of transportation, but running is out of the question. So, jogging is a way to trade energy for time and distance where running trades endurance / distance for time, energy, and speed.
I would assume if humans where built purely for distance running then our most efficient stride would be used for distance running. But, I don't know what the overall tradeoffs are.
PS: There seems to be two definitions of running one of which is a stride there all feet leave the ground at the same time and the other involves high speed. While skipping falls under this definition of running the implication of speed is missing.
Now that thousands of (intelligent) people have wasted hours discussing Joel's insane article, can we all just move on? Please stop posting any more of the duct tape articles.
His say basically is that we should all stop talking about programming and actually program things, because we'll all learn a lot more about what actually works in practice rather than what we think might work.
This is incredibly good advice which I can't seem to follow myself. I'm on HN during the workday instead of getting my damn CSS layouts to resize correctly, after all.
His pages also tend to be butt-ugly. ;-) I get paid to make things pretty, or rather to take the pretty designs that interaction/visual designers come up with and make them actually work, across all browsers, maintainably, with a minimum number of bytes.
In return, when I'm not wrestling with CSS I can play with massive quantities of data and a few zillion machines. Not a bad trade-off IMHO.
