Hacker News Reader

Comment by mysql | Hacker News Reader

Totally agree with this article, there are no immediate consequences to bad CPU bound code. I am seeing the consequences of this at my current position as a Senior Engineer at a startup where a lot of things were written naively, pushed the burden to cloud costs to keep pushing out features.

Something that really taught me to look for things like the "HDD Light" or Fan speed was starting my career in embedded systems. 16 bit MCUs really let you know if you are trying to much on them. They also let you know if you toggle the wrong pin by going up in flames.

The disconnect between your fingers and what actually runs the code is becoming greater and greater for newer developers. It will be interesting to see how computing power keeps up with bad code (it had been doing a good job so far).

View on HN

Programmers don't (can't?) dog food[1] their code because their development machines are Intel Xeon or AMD Threadripper monstrosities with abominable GPUs to match.

Most apparent are the web programmers, most of them assume everyone has 10gbit fiber connections with 16 core CPUs and 128GB of RAM to feed to Chrome. And then they wonder why their shit runs like shit in the real world.

[1]: https://en.wikipedia.org/wiki/Eating_your_own_dog_food

> their development machines are Intel Xeon or AMD Threadripper monstrosities with abominable GPUs to match.

Not all developers. In my entire career, I've never had a development system that was better than the average consumer machine. And, honestly, I wouldn't want one that was, for the exact reasons you state.

Are you certain about that? I’d wager that the average (median?) consumer machine these days is a a smartphone, and not an especially high-end one at that.

Yes, I'm sure. I'm not counting smartphones in this at all, though, because I don't develop apps for smartphones anymore (it's not a market that interests me). By "average machine", I meant a budget laptop or tower.

Yes, but if you need to compile something, isn't it nice to have those threads?

If your software takes that much resources to compile, you may already be on the wrong end of this equation

That's a very weak "may". Different languages and compilers vary in speed by orders of magnitude, when fed similar code with similar running speed.

I've never been terribly bothered by compile times in general. 90% of my work is with compiled languages, and (in most languages) incremental compilation does a great job of keeping compile times low. Even for large projects on slow machines, I rarely see compile times exceed even a minute. More usually, compiling just takes a few seconds.

Sure, you do occasionally need to do a full recompile, and if the project is very large then this can take a nontrivial amount of time, but that doesn't really happen often enough for me to be bothered about.

If the project is of really significant size, or if the compiler/language/code structure is such that incremental compilation can't give you significant gains (or isn't even possible), you may need more grunt of course.

> Most apparent are the web programmers, most of them assume everyone has 10gbit fiber connections with 16 core CPUs and 128GB of RAM to feed to Chrome

Facebook marketplace. I don't know how you can make a grid of images max out a 5800x, but they've managed it. A markedly inferior product to every one of the classified ad competitors they've squashed out of existence.

That is one advantage of being a firmware engineer. In my case, this code runs on exactly one machine (usually) so whatever performance I get is very indicative of what the customer experience is like. My dev machines are usually just unfused versions of whatever hardware I'm working on.

Programmers developing webshits should really be forced to add 200ms to all their roundtrips. It’s worrying how many people assume everyone is 20ms from their “edge”, and openly advocate on HN for “new” technology that requires a roundtrip on every single state change, unwinding twenty years of client side advancements.

As someome who doesn't live in the US I appreciate the nod. Unless the company has edges in the southern hemisphere, every single widget has a round trip of 2-300ms. Something like Jira with it's cascading react components was a jumbling absurd mess until all the roundtrips completed, which could take 10+ seconds. A liftime from a UX perspective.

Funny to have issues with Jira in the southern hemisphere since they're Australian, you'd think they would have figured that issue out.

I would say rather that code badness has been keeping up with computing power increases.

https://en.wikipedia.org/wiki/Wirth%27s_law (May he rest in peace.)

https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law

https://en.wikipedia.org/wiki/Jevons_paradox

https://en.wikipedia.org/wiki/Parkinson%27s_law

https://en.wikipedia.org/wiki/Induced_demand

I wonder if this phenomenon can be generalized under one law, because clearly it pops up anywhere humans are concerned.

CNA I ask how did you switch away from embedded?

Reply on news.ycombinator.com