I think the last point is the best one, and something that I'll try to keep in mind

>

    And what do you do when that awful, black day arrives? Here’s a quick coping manual from those of us who have been there:

    Don’t pretend it didn’t happen — you screwed up, but your mother still loves you
    Don’t minimize the problem, shrug it off or otherwise make light of it — this is serious business, and your colleagues take it seriously
    If someone spent time debugging your bug, thank them
    If someone was inconvenienced by your bug, apologize to them
    Take responsibility for your bug — don’t bother to blame other subsystems, the inherent complexity of the software, your code reviewers, your testers, the community, etc.
    If it was caught before it was running in production, be thankful that a production user wasn’t affected by it

Really? This is all second nature, stuff you should already be doing. Replace "bug" with defect and it can apply to anything.

If you find computer work is stressing you out, maybe find a better job that suits your interests?

> You may discover as you work in the subsystem that maintaining it is simply untenable — and it may be time to consider rewriting the subsystem from scratch. (After all, most of the subsystems that are in the first category replaced subsystems that were in the second.) One should not come to this decision too quickly — rewriting a subsystem from scratch is enormously difficult and time-consuming. Still, don’t rule it out a priori.

It's good to see this important trade-off mentioned. I've seen Spolsky's infamous allegory about Netscape [1] that "[rewriting] the code from scratch [... is] the single worst strategic mistake that any software company can make," used to browbeat people in response to their quite justified opinion that "maintaining it is simply untenable." While Spolsky does go on to nuance his statement a little bit, advocating for a careful refactoring process with lots of tests, I was happy to see the same advice formulated in a way that precludes such cherry picking here.

[1] http://www.joelonsoftware.com/articles/fog0000000069.html

I have to conclude that you didn't make any effort whatsoever to RTFA.

    I half-expect these types of articles to give this tidbit of advice: talk 
    nicely to the computer. It's your friend.

Yep, that's exactly the advice given:

    Run your change in every environment you can get your hands on, and don’t be 
    be content that the software seems to basically work — 
    you must beat the hell out of it