We have all heard the comparison that the average mobile phone is more powerful that the computers that were used on the Apollo project. I used to write software that performed useful business functions while running on a computer with a total of 16K RAM and a tiny CPU. Anyone could. It's just that when we had a lot more power available, we made a conscious choice to let the computer do more of the development, and deliver the business function with less effort on the part of the developers.

The end result is that we can quickly deliver business functionality, but often with large executable files bloated with libraries that we are not even using, and we transmit data packets that are often 80% static text and 20% useful data. And that's all fine, because the systems and the internet are fast enough that it does not matter,

However, I do worry that many younger developers do not think about these things at all. I believe that it is worth keeping in mind that you can chose to trade off execution speed and data packet size for developer productivity and ease of debugging, but it is a deliberate choice, and "If you choose not to decide, you still have made a choice".

For example, node-js is a wonderful tool for developing REST back-ends, and we chose to use it because of the productivity, despite knowing that the resulting system will use more memory and may well be slower than a system in Java or C++.

Similarly, if you are querying a back-end for cars, compare two JSON packet containing

{
   "selectedAutomobileModel": "honda"
}

or

{
   "car": "honda"
}

The first one contains 20 more characters, but the interesting comparison is to the user-entered data. In this example, the user entered (or selected) five characters: "honda". That is the bare minimum information that needs to be transmitted to the back-end. The second example above would send a total of 16 characters, or 220% more than the user entered. The first example would send 36 characters, or 720% more.

In the 80s, I would have reduced the user's choices to a single character, and sent only that. These days, we simply don't have to worry about this - even 36 characters is a ridiculously small data packet.

However, it is useful to keep in mind that this is a choice, and we can chose different options - in this simplistic example, we could chose to pass the user data on the URL to a REST endpoint, and avoid the overhead of JSON.