I would suggest that computer frustration differs from normal frustration in important ways.

Regular frustration is the experience of feeling limited or thwarted in your efforts towards any particular end. It normallly has a number of physical (slow, cold sweat, tightening of the chest, shortness of breath) and psychological (racing thoughts, violent fantasies towards the thwarting party) symptoms.

Computer frustration, however, differs from the frustrations encountered in just about any other domain or endeavour. When a computer becomes the thwarting party, for whatever capricious reason, the psychological symptoms become acute while the physical symptoms disappear, only to be replaced by an intense desire to drink copious amounts of tequila.

Or maybe spending 6 hours reinstalling an OS is just taking its toll on my psyche.

Well, I'm off to find a replacement for Francine.

In my experience, these are some common sources of computer frustration:

  • Using the wrong tool for the job. It is possible to pound a nail into a board using a screwdriver. However, it is much easier to do it with a hammer. Similarly, it is possible to maintain a snail-mailing list or a roster using a word processor -- but a database, even a simple one, will likely serve the need better.
  • Failing to explore the tools before starting in on a project. If you do not know the strengths and the limitations of the various tools you have, you will not be able to exploit the former and compensate for the latter. If you don't know the tricks, you can't use them. You could use a linked list in a Perl program -- but why would you want to?
  • Dumbass attacks and no backups. Eventually, you will execute rm -rf on the wrong directory, scribble on the wrong file, or leave a critical floppy out where the cat can use it for a chew toy. If you are in the habit of making backups, however, you are much likelier to lose your job and/or GPA over such disasters.
  • Preferring bad-but-easy software over good-but-harder software. Sometimes, the best tool for the job is also the easiest to learn to use. However, such a circumstance is sadly quite rare; more often, the easiest alternative is easiest because its designers have favored ease of use over functionality, extensibility, or correctness. Using bad-but-easy software, particularly if you are already familiar with it, lets you avoid some of the overhead of learning a new application -- but exposes you to risks of flaky behavior, style-cramping limitations, and general buggitude.

Log in or register to write something here or to contact authors.