Hacker News Reader

Comment by kcl | Hacker News Reader

In the Gmail Genius vs Clueless Manager comparison, I think it's more apt to say that the genius can traverse the tree and 'drill down' where necessary, applying the most effective changes at the necessary level of detail. The Clueless Manager is always stuck at the highest levels of abstraction, and he can only work with very blunt objects. The point is that the largest gains can sometimes come from optimizing disk-seek speeds, and being able to recognize (and correct) this is an advantage over only being able to talk about performance in generalized terms.

View on HN

I agree. Striking the right balance between abstractions and low-level details, is the mark of a genius. Put differently, the size and nature of the building blocks a person uses, in order to tackle a problem or to communicate with others is, to me, a very good indicator of how smart that person is.

I have been in situations where the balance has tipped far too much in either directions. Far too much reliance on abstractions, without understanding the details and we get the stock, garden variety Business person. Far too many details used in thinking and communicating leads to tedium, and interestingly can come off as patronizing, if its done often enough.

Indeed. I could count one hand the number of times I've heard a Fields Medalist say "And then you carry the one..."

Yeah. Thinking too detailed too early on would be a mistake, too. Thinking about disk heads when you have no idea what the interface will look like is a huge mistake to me.

I don't think web developers have to think about disk I/O unless they're Google or Yahoo.

"... I don't think web developers have to think about disk I/O unless they're Google or Yahoo. ..."

I'm not sure about this.

For "any" interactive Webapp, speed is important. If you have repeated queries to/from, DB I/O does come into the picture when peak loads occur. So right when you get lots of users, the site will be hit. I've seen this with e-commerce (where user speed == $$$) where sure enough every peak time the server(s) would begin to grind. Remember your max speed will be determined by bandwidth. DB I/O will have some effect to slow response times. Maybe not as much as bandwidth but it is still something you must consider. Not every site is as extreme as e-commerce but the idea is still valid.

"... Every Web usability study I have conducted since 1994 has shown the same thing: users beg us to speed up page downloads ..." ~ http://www.useit.com/alertbox/9703a.html

Why is it important? Well user perception is one.

user: "Gee your application is slow compared to google, a bit slower than amazon"

developer: "But google invests squillions in hardware, network connections . Their applications run in memory. My apps run on fast hardware, I optomise for small pages ...."

user: "... So, it still appears slow"

If a user thinks your site is slow (and if you subscribe to the idea that you are creating web applications as apposed to documents) you need to keep your response times as close as possible to applications that people use every day.

It doesn't help that developers constantly throwing new (unoptomised) techniques to do new things at the same time larger sites are optomising to improve their load times, making comparisons between load times inevitable ~ http://developer.yahoo.net/blog/archives/performance/

Reply on news.ycombinator.com