When I was a kid, I used to help my Dad work on the family cars.  We changed the oil, brake pads, repaired a broken hydraulic line, and fixed faulty air conditioning.

It wasn't too long before I was able to do most basic repair and maintenance myself.  In college, I spent hours fixing an electrical problem that caused my rear turn signals to go out.

Recently, my car started to make a weird "coughing" noise from the muffler, and I fixed that, too.

This Is Going Somewhere I Swear

Why is this relevant to programming?  Well, one of my favorite parts about programming production services is forensic debugging.  Some process crashes in the middle of the night and all you're left with is a beeper going apeshit and a stack trace.  What went wrong?  How do you debug that?

Debugging a car is the same thing, but a lot harder.  With a car, the symptoms of the bug aren't usually very concrete: a funny noise, a bad smell, a jittery feeling.  Compared to a computer, a car is a very simple machine, but because it's so simple it's much harder to debug.  Newer cars have an electronic interface to tell you what sensors are indicating faults, but that doesn't always solve the problem.  Plus, the sensor readers are like $300.

The more you work on a car, the more you develop an intuition about it.  In code, you can narrow your bug down and fix it.  With a car, you narrow the fault down to a couple of suspect parts and start by replacing the cheapest one.  For me, fixing a car problem is much more gratifying than fixing a code problem because of the tangibility of it.

So, if you're enjoy debugging and problem solving, you'd probably like auto mechanics.  There are a couple of collateral upshots to it: you save some money, you can give your friends car advice, and you get to buy a bunch of really awesome tools. 

No one can pull your man card when you have a specialized wrench for an O2 sensor.