Earlier quoted context omitted.
> You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable. Your examples are wanting. Wires are also insulated to stop them from touching each other, not just to prevent electrocution. A 12V wire touching another can definitely…
Did you know that when they first implemented electricity they just buried them pinned with nails on wood, no insulation? Back then insulating wires was more expensive than just eating energy losses via running current. Like I said, it all comes down to economics.
Performance Matters (2019)
41–50 of 75 posts
Re: Performance Matters (2019)
#42Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…
Re: Performance Matters (2019)
#43Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…
As a front-end developer my professional experience tells me that in practice the ONLY (cannot stress this enough) thing that matters is developer convenience in the code. Everything else be damned. That said if this UI failure was easier for the developers to code, such as no code and download from NPM, then it is most correct even if both the business and end user are both catastrophically harmed immediately.
Re: Performance Matters (2019)
#44The author made such a good praise of performance that I was half ready to learn ASM to code all my apps ... then he admitted he was using this Electron app because it was more featurefull than the native one ...
Re: Performance Matters (2019)
#45Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…
Re: Performance Matters (2019)
#46What would happen if you replace "performance" in this article with "not contrast enough UI" or "bad autocorrect" or "annoying background music"? Should this article have been "Good autocorrect matters"? The problem here isn't performance. The problem here is that the company which is building this software are so remote from end-user that they don't hear feedback. If they knew that performance is the problem and mul…
I remember back when FogBugz was a thing and Joel claimed that the correct way to provide customer service was track bugs, have one owner, and only allow the original reporter of the bug to mark it as closed. I'm sure that's not completely feasible but It's surprising to me how I know of ZERO software developers that follow anything even remotely close to this practice except for a few open source projects.
Want to report a bug on Windows? Photoshop? Almost any game ever? Good luck finding out if a dev ever saw your report and that it didn't just get dropped by some underpaid customer service center rep.
Re: Performance Matters (2019)
#47This matters more than one would think. I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like people would refuse the use the system, it was the only way to do their jobs. The public had no choice, either. Initially, I didn't think it was such a big deal. Yes it was a bit slow, but nothing _terrible_ and why did it matter, since there were so many other pro…
As a user forced to use many apps and websites with a terrible user experience, I conclude that you can certainly have well-communicated loading times without me hating the product. However, I will always avoid - if I can - using a product where the UI itself is slow, sluggish or bad. This includes many modern websites and also quite a few apps. Responsiveness is the key. If I click on something, then something needs…
Re: Performance Matters (2019)
#48Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…
Unfortunately Firefox is guilty of that Unpardonable Sin. Often I will open a new window to search for something and start typing my request right away, since the address/search bar should be focused on new windows. If the window takes a little bit of time to appear for some reason, the first few characters will be dropped. Frustrating. Chrome on the other hand does not exhibit this defect, even if I start typing bef…
Re: Performance Matters (2019)
#49Here is the full quote: "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%."
What most people do is ALSO pass up optimizing that critical 3%, so software gets slower and slower. What he (probably) really meant is: "don't micro-optimize what a compiler can do better, optimize your algorithms and data-structures"
Some common excuses for bad code:
- Shuffling data around needlessly? Not a problem. It's fast enough.
- The algorithm is bad. Not a problem. It's fast enough.
- This is obviously bad. Not a problem. It already takes minutes, so a few more won't matter.
- The code is slow. Not a problem. It's only used internally.
Re: Performance Matters (2019)
#50I went back and tested the various changes I'd made to that point and thankfully found that most of them were needed to sustain that performance improvement but it was a good reminder to break out the profiler first, not last.