5 ms·

Everything you mention is something that is the concern of a product manager, not an engineering lead. It becomes the engineering lead's problem when the produc

by exelius 10y ago

Everything you mention is something that is the concern of a product manager, not an engineering lead. It becomes the engineering lead's problem when the product manager tells them it is. A huge problem at a lot of companies is when engineering teams go "off script" and build solutions for problems that nobody has. Is it an accident that Google's "10% policy" has largely evaporated as pressures on efficiency and productivity have come in from Wall Street? Also speed on the type of sites you mention is a solved problem. CMSes these days have an option to generate static content and push it to a CDN. Is it free? Nope. But it's a problem with a solution.

oliwarner 10y ago
I don't think I could disagree more with your post. Every developer you have should be capable of weighing up performance ramifications of their decisions, and be able to discuss and justify them. Not saying that every line needs explaining but come on... Not their concern? I'm all for getting stuff done but doing a crappy job the first time more than doubles the TTL. Moreover, telling your developers to ignore this stuff means it becomes a lost skill. When you do need them to double-back and profile and bisect everything back to 0AD, they'll be much less capable than a performance-conscientious developer. I don't disagree that over-optimisation is a thing, but a hands-off approach is far more toxic. Big ticket optimisation rewrites should not be something a single developer takes on without their lead signing off. Letting developers do that is a management issue. And "the type of sites I mention[ed]"? I think you misread my post because I was very explicitly talking about e-commerce and webapps. Not CMSes and not usually something you can run entirely static from a CDN. And just because it's static and/or on a CDN doesn't mean it's not bloated to hell and back; that's really the point TFA is making.

by exelius 10y ago

oliwarner 10y ago

I don't think I could disagree more with your post. Every developer you have should be capable of weighing up performance ramifications of their decisions, and be able to discuss and justify them. Not saying that every line needs explaining but come on... Not their concern? I'm all for getting stuff done but doing a crappy job the first time more than doubles the TTL. Moreover, telling your developers to ignore this stuff means it becomes a lost skill. When you do need them to double-back and profile and bisect everything back to 0AD, they'll be much less capable than a performance-conscientious developer. I don't disagree that over-optimisation is a thing, but a hands-off approach is far more toxic. Big ticket optimisation rewrites should not be something a single developer takes on without their lead signing off. Letting developers do that is a management issue. And "the type of sites I mention[ed]"? I think you misread my post because I was very explicitly talking about e-commerce and webapps. Not CMSes and not usually something you can run entirely static from a CDN. And just because it's static and/or on a CDN doesn't mean it's not bloated to hell and back; that's really the point TFA is making.