[didgetmaster]

> Our philosophy is that to make fast software, you need slow computers...

One of the reasons why our industry produces slow, bloated software is because the engineers building it often have the fastest computers with the most resources. It should be a requirement before shipping to have your whole team personally use the software for a week on 10 year old computers.

One of the reasons why my data management system (https://www.Didgets.com) is so fast is because I regularly ran it on an old Core-2 Duo machine with a slow hard drive and limited RAM. I didn't stop tweaking it until it ran fast on the old hardware.

[pjmlp]

Best example how bad this is, using Android Studio studio in computers that aren't gaming rigs, apparently Android team cannot be bothered to make it usable.

Optimizing Android builds and decreasing Android Studio resource usage tends to be a common talk at Android related conferences.

[andromeduck]

My first internship involved compiling android about once a week on a dual core 20 Gb machine. It took HOURS to build almost anythining from scratch.

[1vuio0pswjnm7]

Running the software on an underpowered computer as a test is admirable. I go further. Where possible, I actually write the software on an underpowered computer, preferably the one it wil run on. Because in addition to wanting the software to run quickly, I also want to be able to edit the software and re-compile quickly.

Sometimes it is not possible to compile the software on the target computer, e.g., an MCU, but we should still be able to compile and flash the MCU software using underpowered computers. We should not need a large, graphical operating system and graphical software to create software for tiny computers that do not support graphics. I continue to be baffled by the large, graphical Windows software people use to program MCUs. There are exceptions,1 but they seem rare.

1. For example, https://github.com/PaulStoffregen/teensy_loader_cli