Yes, power cycling most often treats the symptom, not the problem. As a consumer, you often don't have a way to treat the problem, so that's your only recourse. As an engineer, or really anyone capable and responsible for fixing the problem, often you do not want to power cycle, because if the problem goes away you may no longer have a way or reproducing it. That makes most problems harder to fix, and possibly impossible to confirm fixed.

I often reduce how I classify the importance of bug reports I get that I can't reproduce. It's often not efficient to work on something with so little information to go on. Further information on the bug or a reproducible error case vastly help.

The real problems start when your support organization thinks that rebooting the customer's machine is a solution.....

Then the engineering team never gets to fix the problem, and your support team starts eating up all the resources because they get constant calls from the customers asking about the same problems.

(thankful for not being in that job anymore!)

Experience allows an Engineer to tell when a problem is one that needs fixing, and when its one that just need a reboot, so many problems with technology are transient, as in not reproducible in any meaningful way (or rather commonly occurring way), yet we spend the most energy (In My Opinion) on those.

Well, if it works for a day:

    1 0 * * * kill -HUP $(cat /var/run/my_server.pid) >> /var/log/my_server/error.log

You think I've kidding but I've done this in production. Now I'm more likely to use god/monit.

In fact, not joking at all: this is how I make Finder not slow down. Every 4 hours, I restart it via crontab.

On the other hand, there are languages and platforms like Erlang, which are designed around "managed" power cycling your processes.

'You have a point, but your point is conceptually "state is bad, build things with the least state possible".

Even though I agree with this, there is a fundamental difference between computer science and software engineering, and in actual software engineering there will often be hacks, and bad state. Even if sometimes it's not yours, but a library you're using.

I agree with you, but this article deals with a more "real life, pragmatic" approach, versus your thesis which is true, but a little more idealistic

Really? My definition would have been the opposite. When you call yourself an engineer you're saying you're like structural engineer building a bridge or an aeronautical engineer building a plane. You're saying you have a professional and moral obligation to do a good job.

Any company that expects its developers to take pride in their work should track crashes and strive to produce software that doesn't routinely need to be restarted.

You have to be careful there though. When it comes to computer software even perfect code can require a restart if different code on the same machine is interfering with it. The story has gotten much better but even now occasionally I'll have a reboot a Game or 3D visualization app because the graphics driver got wedged. It's not the applications fault it's the drivers fault.

The reason power cycling is such a useful tool is that most computer systems are running in an environment where the things outside of it's control way outnumber the things within it's control.