User time is more valuable than programmer's time. Read: programmers should operate as if CPU cycles, RAM, disk space etc is precious. Less = more.
Why? If programmer builds something only for him/herself, or a few of their peers, it really doesn't matter. Do as you like. But be aware that one-off / prototype != final product.
Commonly held view is that programmers are a small % of population, thus their skills are rare (valuable), thus if programmer's time can be saved by wasting some (user) CPU cycles, RAM etc (scripting languages, I'm looking at you!), so be it. Optimize only if necessary.
BUT! Ideally, the programming is only done once. If software is successful, it will be used by many users, again & again over a long time.
The time / RAM / storage wasted over the many runs of such software (not to mention bugs), by many users, outweighs any saving in programmers time.
In short: fine, kick out a prototype or something duct-taped from inefficient components.
But if it catches on: optimize / re-design / simplify / debug / verify the heck out of it, to the point where no CPU cycle or byte can be taken out without losing the core functionality.
Existing software landscape is too much duct-tape, compute expensive but never-used features, inefficient, RAM gobbling, bug-ridden crap that should never have been released.
And that developer has a beefy machine doesn't mean users do.
I have always been of the opinion that no software should ever be released until the entire development team has spent at least a week personally running it on ten year old hardware. Nothing motivates a programmer to optimize their code more than to have to experience the same pain that users without the beefiest hardware have to endure.
iOS versions are obsolete within 2 years and Android within 5.
Generally, Android devs tend to have at least one Huawei, Xiaomi, or low end Samsung, because these break a lot and hold a good share of the non-American market.
However, the high end phones have their own pain - notches, fold, edge screens. I've built apps that didn't function well because the edge screens meant that buttons needed extra side padding because they fall off the screen. These are also the devices used by investors & in demos, so often high end phones are higher priority than the low ones.
There's some problems that have nothing to do with device age. Samsung gallery is one of the top image/file picker apps in the world and there's weird behavior once it exceeds 2000 images or so. I ended up hacking a file/image picker that was more optimized than Samsung's and it's why you see why many apps defauting to their own internal file/image pickers.
Why? If programmer builds something only for him/herself, or a few of their peers, it really doesn't matter. Do as you like. But be aware that one-off / prototype != final product.
Commonly held view is that programmers are a small % of population, thus their skills are rare (valuable), thus if programmer's time can be saved by wasting some (user) CPU cycles, RAM etc (scripting languages, I'm looking at you!), so be it. Optimize only if necessary.
BUT! Ideally, the programming is only done once. If software is successful, it will be used by many users, again & again over a long time.
The time / RAM / storage wasted over the many runs of such software (not to mention bugs), by many users, outweighs any saving in programmers time.
In short: fine, kick out a prototype or something duct-taped from inefficient components.
But if it catches on: optimize / re-design / simplify / debug / verify the heck out of it, to the point where no CPU cycle or byte can be taken out without losing the core functionality.
Existing software landscape is too much duct-tape, compute expensive but never-used features, inefficient, RAM gobbling, bug-ridden crap that should never have been released.
And that developer has a beefy machine doesn't mean users do.