Between disk encryption, anti virus, IT asset management, data custody tracking, etc; my PC is as slow as molasses.

Unfortunately I think its slow in a different way that low-spec machines are slow. Mine is very slow on IO ops, but I have 32GB of RAM and a 20-core i7, so plenty of resources available even after all the BS.

However we DONT want annoying "my computer slow" calls. So we can talk.

But you need the antivirus and some kind of intune/rmm software, sorry.

The company can live with your loss of productivity because it is living with the loss of everyone's productivity. The company cannot live without security.

On top of that, if you are the only one making noise about slow computers and complaining about stuff and things then you eventually end up being the problem. I mean, why is that lone employee complaining so hard about wanting to remove security assurances from his machine?

We tried. Managemen and sales _love_ Microsoft Office. Guess who has the money and makes purchasing decisions ? In the mean time we have to live with (the new and improved) PSpice forgetting its settings from one day to the other. Or with (rolls drum) Teams.

It does not have to be crap actually, I have seen companies with usable machines.

O365 on the other hand, I don't see a solution, it's horrible.

I guess this is the mantra they used to redesign the Windows UI. It didn't work (they stopped at 15%). Now all they do is to use the same mantra to start over and over.

He wanted me to get a better machine.

I politely declined indicating that this is the low spec machine, he made a fuss and I said if we can't make it run on that then we should stop making video games.

For context: The weak part for us was the CPU; the ARC A750 is a pretty poor GFX card but it should never be unplayable, it's around RTX 2060-2070 in speed, not unreasonable for a low spec machine.

It's very easy just to say yes to creeping performance demands, even in video games that are historically highly optimised. (obvious caveat here: sometimes things are not well optimised and hugely neglected)

Luckily, Chrome has a feature to deliberately throttle the CPU and network speed for precisely this reason.

Sadly hardly anyone uses it.

This feature is currently part of devtools. But if it could be enabled as part of Chromes policy engine, then IT departments could enable it by default for all developers, managers, and everyone working on the product, specifically for only web URL's of the product itself.

So: If you want to help solve the fact computers are slow for everyone, probably one of the most impactful things you could do is to send a PR to the Chromium project to let the network and CPU slowdown code[1] be possible to activate from the policy code [2].

[1]: https://source.chromium.org/chromium/chromium/src/+/main:thi...

[2]: https://source.chromium.org/chromium/chromium/src/+/main:chr...

It would be great if Chrome's Developers would use something similar to run Chrome itself.

Forcing them to CARE about targeting benchmark/latency metrics is the sticking point. And that requires shoving their face in it for long enough that it becomes unbearable.

If anything, give the C-suites the shitbox laptops.

It's the devs that need the slow machines -- they're in the tightest feedback loop, and directly empowered to optimize performance.

In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the engineer crosses over a boundary and becomes part of leadership.

Tons of software would run faster if it DIDN'T use custom stuff. Don't load a JavaScript framework for form validation if using `required` and `pattern` are enough. Don't write your own sorting algorithm unless it's faster than qsort(). Don't write your own data storage engine if SQLite covers your use case.

Story time: I once wrote a memset() replacement because one compiler kept optimizing out my memset() call and didn't have memset_s(). It slowed my program down a lot. When I looked carefully I saw I was always resetting the whole buffer, even though I was keeping track of how much had been written to it. Fixing that lead to a ~10x speedup (0.1s to process a large word processor document went to 0.01s, occasionally 0.02s).

Most software is made by stitching together off-the-shelf components. I don't think people on the web need a warning about not writing too much custom code. The HN complaint about the web is regarding bloat from people who walk the mainstream road of web development. Loading a bloated framework to do whatever is an example of such mainstream development.

In many cases, taking performance into account up front adds little overhead and won’t appreciably affect the design. But, if you codify some algorithmically inefficient approach into your public API, you’re going to find that hard to unwind. The engineering team should advocate for that when designing the product.

A common complaint on HN is bloated web performance. Surely we don't think the web is bloated because of too much custom code as opposed to too many off-the-shelf components?

You want the fast machine because you want the code-build-test cycle to be fast, but for immediacy reasons we want a little more hardware than we really need so that we don't get bogged down too badly in worst-case scenarios.

So when we run the software on the machine along side this behemoth, we may or may not see something comparable to the users.

And then we also like for interactions to go faster for us so that we can quickly get to the end of a thought without having to drop everything and fix the slowness first (also, too few of us actually know how to fix the slowness instead of papering over it).

As we lean into multiple machines, or at least virtual machines, I can see a sliver of hope here where we offload rather large chunks of the IDE to resources the application itself cannot 'see', due to partitioning, remote calls, or both. Things like running the language server elsewhere, or the application in a container.

But then you talk to end users and it turns out they work 80 hours on one big document with input lag of several seconds. Some actions can take 15 seconds. It’s mad. It’s larger than anything we imagined anyone to work on. It must be infuriating. And they don’t get beefier machines despite it being an instant cost saving. Because software is seen as magical anyway. They do in two days what would take 50 days to calculate by hand! That’s fast! So when you ask them what to prioritize surely they say “make it faster with heavy documents”? No, they want more features. Because a feature can save then days or weeks or months. A faster program just saves them hours. So I sort of understand them (and why we build software that grows slow).

The machine performs half of 12 boring jobs at the bank needed every month. But there is still another half dozen jobs the IBM still cannot do. It doesn't have the punch cards. So the roomful of smokers does the rest of the jobs in a couple of weeks, ready just in time to start over with next months tasks.

Should IBM make the machine or its programs twice as fast, or have twice as many features, even if the programs are half as fast? They should double the amount of features. And double it again, and again, and again...

But scale those "close to nothing" downsides times 7billion people, 100k seconds in a day, 365 days a week. And suddenly, the ammount of time and electricity alone wasted on something like, waitiing for windows explorer to start, adds to real world scales.

...But also, this implies that optimizing is inherently costly. Which is not always the case. Just the culutre of 'not caring' makes things go slower then they could, while still using the same high level languages etc.

That's BS. Like there was no such things as featuritis and unreasonable schedules.

When performance HURTS so much that they are forced to care about it ABOVE the pressure of features and schedules, then we get somewhere.

Which is why browser emulation doesn't work -- it doesn't inflict enough pain. They wince through it, say "well that was awful, back to rushing more features out the door" and forget about it.

That won't happen because management people are the ones with Bugattis. You got the wrong target.

There might be a case for specifically running testing on a slower machine, though.

> It means their app will feel slow no matter what.

If you can make it feel fast or at least responsive on your underpowered machine, it should feel super fast on everything else. Even today's slowest machines can run some things fast. It does depend a bit on your market though; it might not be worth the effort, but there's a lot of applications out there that could use some speed.

How so? Do the heavy tools need to run alongside the app? Are you thinking of something like Android emulator? For that scenario, keep the beastly workstation, but switch to a $150 phone.

Straw man. Of course, if you crank that knob to the extreme bad things happen.

There might be a case for specifically running testing on a slower machine, though.

Agreed here. I think the optimal is for devs to be able to do intensive operations on a fast machine, dogfood for most of their time on a average machine, then test on a somewhat slow one.

On mobile I've always gone back to testing on low end hardware, there are just too many inconsistencies when trying to simulate slower performance, outdated OS problems, touchscreen drivers, etc.

Giving bad tools to any professional is a bad idea for productivity. We have other ways of checking if software is slow.

It is all a question of company priorities as there are no professional standards whatsoever established. And companies ofc go for spend the least they can get away with.

(second-hand information) Android was at a smoothness disadvantage vs iOS for a long time, because it was never an organization level priority for devices to scroll at >= 60hz without stuttering. Then some executives went "why is scrolling so bad on our phones but not on Apple's?" and suddenly it became a priority.

I remember before the priorities changed, some of their graphics programmers were very frustrated that they didn't have the freedom to invest in fixing it.

Slow laptops for developers test neither of those scenarios!

The solution is to use network emulators that can buffer packets and simulate latency. (Or just put servers in a remote cloud region instead of the local LAN.)

For databases, the trick is to give developers a slow database server with full-sized data. Don’t use empty databases (schema only) during development!

That is exactly what Michael Brown, founder of Central Point Software, insisted on back in the 1980's when they were producing the #1 selling PC software according to PC magazine.

An informed market also helped. A little bit earlier there was a comparison review published (same publication, IIRC) of the top spreadsheet programs (spreadsheets being the reason office workers were getting PC's). MBA Analyst was the best, in everything except speed, much better functionality than Visicalc, MS Multiplan or Lotus123, and only slower by a difference few users would notice without a stopwatch. MBA Analyst vanished in a flash after that article came out, and it found such a stable oblivion that it doesn't even show up on google nowadays.

Most of the programs I use day-to-day are (a) decades old, from the distant past before so-called "tech" companies existed and/or (b) written primarily by single authors, often as a hobby or as a result of itch-scratching. Some of them are written by me.

When I occasionally compile and run the scripts and small programs I write on more powerful computers, I am amazed at the speed. Everything I write is compiled on "low-spec" computers. Today's hardware is amazing.

[1] https://css-tricks.com/test-your-product-on-a-crappy-laptop/