Totally agree with this article, there are no immediate consequences to bad CPU bound code. I am seeing the consequences of this at my current position as a Senior Engineer at a startup where a lot of things were written naively, pushed the burden to cloud costs to keep pushing out features.
Something that really taught me to look for things like the "HDD Light" or Fan speed was starting my career in embedded systems. 16 bit MCUs really let you know if you are trying to much on them. They also let you know if you toggle the wrong pin by going up in flames.
The disconnect between your fingers and what actually runs the code is becoming greater and greater for newer developers. It will be interesting to see how computing power keeps up with bad code (it had been doing a good job so far).
I used to be a computer engineer working on embedded systems for automobiles. Quiescent current is what the normal proper draw is called for these systems when the car is off. We worked very hard getting these numbers in spec but it was hard to catch everything especially in this case where the issue is probably due to software missing the sleep state for that module. This could be from bad code or your CAN/LIN bus is messed up in your car. 99% of mechanics (and engineers) have no idea where to start with debugging these issues and the answer will be "replace the module".
There were a few reasons to switch. I was working in the automotive industry where building anything is a race to the bottom. "How much cheaper can we make this than our competitor" was how design decisions were usually made. Software was the bottom of this list as manufacturing doesn't see it as a profit driver and mostly as an expense. I was in a pickle because I loved the projects I was working on... Ultrasonics, Radar combined with some sort of actuator or motor. Lots of FFTs, debugging boards, soldering, learning Altium and a great boss but I was always pulling nails to get money for projects. I knew I wanted to work somewhere else where the product was software / electrical hardware and I was having a hard time finding the right fit.
After talking with some friends who do webdev (Node, Python) I learned JS in a couple of weeks and got hired into a consulting firm where I worked for 6 months building a document search engine in C# on top of ElasticSearch. I now lead a team at a small firm that builds specialized search applications for different parts of the internet.
I now know of places that have the software culture (and software money) that do embedded systems well but I love what I do now with no shortage of cool problems to work on. Not sure if I would go back into embedded but I still dabble with Arduino's and Pi's.
Before becoming a web developer I worked as an embedded systems dev for a few years. That experience left me with valuable skills in data structures (Everything is C), understanding how a processor works and executes instructions and hardcore debugging.
Not sure if I would recommend building a career in embedded but you will start learning transferable skills doing it in your free time.
Something that really taught me to look for things like the "HDD Light" or Fan speed was starting my career in embedded systems. 16 bit MCUs really let you know if you are trying to much on them. They also let you know if you toggle the wrong pin by going up in flames.
The disconnect between your fingers and what actually runs the code is becoming greater and greater for newer developers. It will be interesting to see how computing power keeps up with bad code (it had been doing a good job so far).