> No one has ever made a purchasing decision based on how good your code is.
As stated by others, this is very false. Most if not all software I use is selected by its disk/memory footprint and performance. Having a small disk/memory footprint and having good performance at the same time is a good indicator of a good code quality.
Moreover, after using computers for more than three decades, you get a feeling about the performance of a particular software suite. So an inefficient piece of code makes itself known in a loud way if you look the right way.
One of my favorite applications, Obsidian, is generally performs well, but when you hit it just the right way (e.g. add a couple of PDFs and enable previewing), you can feel how sluggish it becomes.
Having a suite of well written applications which have high performance/footprint ratio also allows me to do more with less resources and in less time. So, good code quality matters. It also almost guarantees the software suite will be maintained in a longer time.
Incidentally, I'm also in camp #2, and write my code with the same attention to detail. I have also written code which squeezed all performance from systems, approaching theoretical IPC limits of the processor the code is running on.
I've built dozens of services and applications for companies.
ZERO times has anyone even mentioned disk/memory footprint. Performance maaybe, but no hard limits were defined in any contracts. And even those were "these things have to be processed within 24 hours because the law says so", not microsecond precision.
Even Obsidian is 440MB. It's a markdown editor with a built-in javascript scripting system. There's no reason for it to be almost half a gigabyte. Zero people have checked the directory size and went "nah, too big, won't use it".
> Zero people have checked the directory size and went "nah, too big, won't use it".
Nope, at least one. I refused to install software just because it's too big. I resisted using Obsidian exactly of these reasons until I failed to find a credible alternative.
Well, there's ZimWiki, but it wasn't working on macOS well enough to use that daily.
> Most if not all software I use is selected by its disk/memory footprint and performance.
If that would be true, electron apps would not exists and everything would be a native software. But alas, most modern products, even before vibe-coding are horrible performance-wise.
Of course it depends on the context, but consumer facing products have been awful in terms of performance for a while now.
As stated by others, this is very false. Most if not all software I use is selected by its disk/memory footprint and performance. Having a small disk/memory footprint and having good performance at the same time is a good indicator of a good code quality.
Moreover, after using computers for more than three decades, you get a feeling about the performance of a particular software suite. So an inefficient piece of code makes itself known in a loud way if you look the right way.
One of my favorite applications, Obsidian, is generally performs well, but when you hit it just the right way (e.g. add a couple of PDFs and enable previewing), you can feel how sluggish it becomes.
Having a suite of well written applications which have high performance/footprint ratio also allows me to do more with less resources and in less time. So, good code quality matters. It also almost guarantees the software suite will be maintained in a longer time.
Incidentally, I'm also in camp #2, and write my code with the same attention to detail. I have also written code which squeezed all performance from systems, approaching theoretical IPC limits of the processor the code is running on.