I talk about code that I can shrink by a factor of 2. Most often without even understanding what the code does, just applying local correctness-preserving transformations.

I'm talking about horrors such as (this was real, production code):

  bool flag = true;
  if (var1 == const1)
  {
    if (var2 == const2)
    {
      // quite a lot of code
      flag = false;
    }
  }
  if (flag == true)
  {
    // a little piece of code.
  }

Clearly, someone forgot to clean up their code. It doesn't take a Master of Succinctness to realize that

  if (var1 != const1 ||
      var2 != const2)
  {
    // a little piece of code
  }
  else
  {
    // quite a lot of code
  }

is much better (the code represented by the comments didn't touch the flag). Plus, such simplifications tend to compound. After a first pass, I often see more possible reductions that can be used for a second, sometimes a third pass.

I like your driving analogy. It's very true. Those who talk the most shit often are shit, like how some men call women bad drivers even though women are actually less costly to insure.

Bad driver stereotypes piss me off because they often work under the assumption that cautious drivers are bad drivers and aggressive drivers are good drivers. Hell I bet Asian women are really the safest drivers.

There are a number of experiments that suggest that overall, the best predictor of shit (mostly, cost and bugs) is size. Once you account for size, almost every other predictor tend to be more noise than signal.

So, while there are ways to make code so short that it becomes incomprehensible (code golf?), most of the time, less code is almost always a good thing. A case in point would be the factorial in Haskell:

  fac i = product [1..i]