Hacker News Reader

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. "

-Donald Knuth [1]

[1]https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=...

>>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.

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.

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.

> 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.

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.

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.

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.

>>unless you've got a confirmed performance problem, you shouldn't think about it at all.

I like to write high quality code that I'm proud of. This means code not just works, but works efficiently and fast. It goes back to what Steve Jobs said once:

“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

That said, this is more of an ideal to strive towards and it's not always possible. Sometimes there are tight deadlines that need to be met, and something has to give. In such scenarios, I agree with your order of priorities: 1) code that works, 2) code that works well, 3) code that works fast.

Absolutely - I love digging into the core of frameworks & the language itself to eke out every last bit of performance. But that takes time, something I'm usually short of. All of the examples given in the article weren't neat perf side projects, they were live sites with customers & deadlines. I write the best code I can given the constraints I'm under.

Given the chance, we'd all like to write perfect code but reality tends to interfere.

Interesting to note that generally even quite nice sets of draws have cheap wood at the back...

Yeah, what kind of asshole carpenter wastes his customer's money by inflating materials costs for no reason?

The same kind that was the CEO of one of the most successful companies in the history of the world.

Steve Jobs may have missed the mark on some of his products during his long tenure at Apple, but his focus on quality in every possible area of what he had a part in creating has paid its benefits

One I would pay, because he values quality over ROI optimization. Something I look for when choosing craftsmen to work for me.

You have watched too much Norm Abram. Put down the remote and go outside.

Sometimes there are tight deadlines that need to be met

Where would you say these come from?

> most of the time the code runs fast enough

Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.

I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.

So terrible performance is OK if it's caused by ads & trackers? They don't count as part of a page's Javascript payload?

If you're going to complain about the slowness of pages because of the idiosyncrasies of one library over another, then complain about that.

If you're going to complain about the slowness of pages due to trackers and ad servers regardless of which library (or none at all) is used for primary content formatting, then complain about that.

You're talking apples while holding up an orange.

Use Firefox Mobile with uBlock. It's been a long time since I've seen ads on web

Depends. There's been lots of studies linking page speed to revenue. I would imagine it doesn't manifest much in lower traffic sites where there's too much noise for it to play out, but as you grow in your userbase, working fast starts to become necessary for it to work well.

The tone of your comment sounds like you think I said one should never look at performance. I do this professionally, I should hope folks out there need performance. Let me be clear: A developer should place performance priority in the Right Place, and a good dev will know where that is.

Would you mind linking a few of these studies? I'm curious as to what the point of diminishing returns is.

nngroup [0] says that 100ms feels instantaneous. A good digest cycle run (the basic unit of Angular performance) is 16ms, a mediocre one is 20ms. So a mediocre application has 5x space to grow before the app stops feeling instantaneous.

[0] https://www.nngroup.com/articles/website-response-times/

>So a mediocre application has 5x space to grow before the app stops feeling instantaneous.

Not really. Those 100ms are from click to render done, so you also need to account for the physical transmission latency, the transmission of the data and finally the rendering (which is where your 16-20ms are).

And you upgrade your machine not when the response time goes up, but when the response time goes up too much.

And what makes it OK to burn X% additional battery life across all your users devices?

I take your general point but battery life is also a problem I have with React Native. Sure, you can drive animations from the JS thread and on modern devices in some cases you can't even tell the difference. But your battery can.

do you have any articles discussing react natives increased battery usage? why would it be any more than a native app?

Tried this out on a work project a month or two ago, found it worked quite well and had a noticeable performance boost.

Unfortunately a bunch of inherited legacy code uses angular.element().scope() in a lot of places which then breaks without this turned on, so I had to revert it.

Some deoptimizations are ahead-of-time planted to make performances increases easy to enable in the future.

http://thedailywtf.com/articles/The-Speedup-Loop

I have a better solution to this problem.

I optimize one module at a time, and I optimize it deeply. The number of people whose stuff I might break is kept to a minimum, the surface area of regression testing is controlled, and next quarter when they ask me for more power I can repeat it, until I run out of modules (hopefully someone will write some more in the meantime).

The whole idea of the Tall Tent Pole is pretty enticing, but the thing is nobody is ever gonna buy into going back for the last 20% in any one part, and these things always have a multiplicative factor. If you're in a field with no competition, this isn't a big deal, but how often does that happen?

Is there a linter or some such which will catch the most common of these mistakes?

1) Make it work

2) ???

3) Make it work fast