The thing about when the audio-editing software “Audacity” crashes on you (which it has done on me several times tonight) is that at least you get to step back from your standing desk and throw your arms out and exclaim “How DARE you have the AUDACITY to just suddenly lock up right THEN!? When I was in the middle of that THING!”
And that’s a bit of a relief.
But not as much as when the basically-perfect disaster-recover means your break from doing that THING is basically only as long as it takes to amuse yourself over the name of the software and then remember to save more often.
It is not the same with Git.
It takes far longer to recover from a Git disaster than an Audacity crash and it’s far quicker to amuse yourself over insulting it.
Of course, Git never really crashes. But when it does go wrong it’s usually my fault. Or a co-worker’s fault. Usually a co-worker’s fault and I have to come rescue it really.
I end up glad feeling I use software with a good disaster-recovery system more often than I feel glad my software didn’t crash.
It’s like the sys-admin who is only noticed when he fails at his job and things break, then he’s called a hero for finally fixing it if he does so quickly enough. If it gets it right in the first place, nobody really knows what it is he does exactly.
Perhaps the ideal software would occasionally, if it noticed you hadn’t saved for a while, when you appeared to be in a bit of a break, would say “Woah, I nearly crashed right then! Good job my anti-crash skills are so awesome!”
It’s hard to bill at work for the number of mistakes you nearly make. Which is why it’s hard to estimate software development times.
Anyone telling me I ought to use spying controlling expensive but more polished software than Audacity knows which /dev they can direct their comments to but if you know something better, cross platform, more free AND less expensive and isn’t Ardour (which is also great, but at different things) then let me know about that, for sure.