back

by dmitrygr·10y ago·view on hn ↗
>>The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough

THIS!

This is why battery life on mobile sucks

everyone who thinks this way is the reason

.

As everything moves to the web, the performance of your code matters

.

So what if my phone has just enough CPU to render your site? You should not be content with that - you should strive to use less, so my CPU can go to sleep faster.

.

Your job is supposed to be hard. you're an engineer! Please consider the consequences of your actions.

4 comments
> Your job is supposed to be hard. you're an engineer! Please consider the consequences of your actions.

My clients pay my wages and they are the ones who choose what my priorities should be. Where are these mythical developers who get to choose how long to spend on optimising working code without any financial imperatives? Outside of hobby projects there's always someone counting the pennies.

As a consultant, my clients do not dictate at all what my priorities should be. I work with them to identify what their priorities are, what they'd like to see done. I train them to value performance and quality, not the lowest bottom line. I also train them to learn how to identify performance and quality. I give them feedback on their ideas/priorities, and always include my own suggestions for platform/software maintenance/improvement/enhancement. I'm their consultant and vendor, not their employee.

I probably take this to a weird degree for some, but I actively think about my client's software quite often, and frequently toss ideas their way whenever they hit me. You'd be surprised how often those ideas--which I thought were cool, hence the sharing--come back later as something they want. It's just basic sales.

Of course, I'm always building large, custom projects from scratch, not taking on projects that ask me to optimize "working code without any financial imperatives". On the other hand, when I identify a part of their software that can gain performance or some other kind of improvement—say, some dependency has improved that will ease X, making priorities Y and Z easier to implement—they listen to me and put it in their list of priorities.

Everybody wins.

I agree, but this is a moral imperative, not a financial one. And before you say "it's immoral to spend the client money on things they don't want", you're right. Your job is to convince the client it is "worth" it.
So, what have you done to improve the situation?
My philosophy: As a professional, you should always consider the user of your product to be your client, whether they're paying you or not.
Only in this specific case it's exactly one line of code. Unless your hourly rate is obscenely high it is essentially a free optimization.
Hopefully in the future browsers will show bandwidth and energy use per domain.
You don't even need a mobile phone to prove that. Every Adobe desktop software iteration takes twice than the previous one to open and offers pretty much the same functionalities just arranged in a different manner. And buggier.
I like this comment and I'd add one more thing:

Yes developers your developer-time is the most precious thing in the universe but please consider your user's time and their computing resources as well.

It's a customer's decision, not a developer's one. A one liner like the one in the post should be added at zero cost by any developer, but more important optimizations compete with the budget of the features that sell the product of the customer. In my experience customers want features first, optimizations last and only if the unoptimized app/site runs too slow on their devices. And developers don't like to work for free.
Even if the customer doesn't demand it, you should have your own standards for quality and performance and never compromise on them when it comes to your deliverables.

You're actually harming your business if you choose to do shitty work for small bucks and good work for big bucks. If you take your standards very seriously it improves the capabilities of your team and let's you take on more lucrative contracts.

> And developers don't like to work for free.

Oddly enough, the highest earning developers I know don't think like that.

I understand your feelings but I don't think they match the reality of many places around the world.

Maybe those developers earn so much that they can provide quality even if their customers don't explicitly demand it. But we can look at it in another way: their customer pay so much because they also pay for that quality and take it for granted. Deliver to them an unpolished product (in any way) and somebody else will code the next one.

Unfortunately not all customers are like that. Many of them fight for every single dollar/euro/whatever. They know they are compromising on quality and accept the tradeoff. After all, it's their privilege to decide the limits of their budget and maybe there is nothing they can do about it. The developer must accept it too, get the job done as quickly as possible and take another job. Or do very few and very long high quality jobs at unbearable costs and end up bankrupt quickly (and possibly piss off the customer because you're taking so long to deliver.)

Btw: customers give constraints also on time. There is no time to provide much quality when they want a feature delivered in a couple of days on a system you never saw before. It happened to me a few weeks ago. I made it but I could have done it better if I had at least one week? Sure. Would they pay me twice as much? Nope.