> "Bulldozer code" that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)

I feel like this might give people the wrong idea. Surely some amount of cohesion is desirable. Also, I'm not quite sure how one "gives the appearance of refactoring" without actually refactoring. Whether it's useful or not may enter into it, but I would usually consider the breaking out of chunks into subroutines refactoring.

I once dealt with code that looked like this pattern (sorry for the giant vertical size of this post):

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    B;
    C;
    D;
    G;
    H;
    I;
    J;
    A;
    B;
    C;
    H;
    I;
    // a bunch more
  }

So I suggested, "hey perhaps you should break this into functions" and got back:

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    state.a = a;
    state.b = b;
    // ... for other state
    return DO_F2(state)
  }
  DO_F2(state);
    B;
    C;
    D;
    G;
    H;
    I;
    state.a = a;
    //...
    return DO_F3(state);
  }
  DO_F3();
    J;
    A;
    B;
    C;
    G;
    H;
    I;
    // a bunch more
  }

When I suggested blocks such as B; C; D; or G; H; I; could be functions, and perhaps a loop could be useful too, the guy looked at me like I was trying to do voodoo and got really defensive about how that couldn't possibly work.

I think that is what the OP meant by bulldozer code...

Not only that, the purpose of refactoring isn't simply for reuse, but also for readability. If you break out chuncks that aren't reusable, but enhance the readability of the code then you've likely improved the code.

Given the choice between reusability and readability I'd say that readability should usually win (although it is a false choice).

I would contend that if you're having code readability issues, it'd be better to fix it by sprucing up your whitespace and comments, instead of saying "Well, let's chunk it into more functions" and have method(), which returns method1(), which returns method2(), which returns method3()...

Chunking for the sake of itself doesn't seem like a viable strategy to me.

When you add a new-line or two into a section of code, you're usually saying:

"These two blocks of code do something different"

Thats what is normally called a method. If it's only for one class then by all means make it private and name it well, so the caller remains readable.

Chunking out in more functions is good in itself, because there's usually a well defined interface for what can get in and out of a function.

Whitespace and comments can suggest that some pieces of code don't interact that much, but chunking into functions lets the compiler prove it.

I agree that that strategy's pretty feeble, but IMO it's still better than e.g. a thousand-line function. If nothing else it forces you to break out the parameters explicitly, instead of just having a thousand lines of intermingled state transitions.

Fully agree and I want to add, that it is also a requirement for writing good, simple, small unit tests. Clean code means, a function should only do one thing and that's the thing you can test.

I find this is one of the things I struggle with the most. I definitely "refactor" code by moving it to a subroutine sometimes purely for readability's sake. I also try not to stress out about how reusable something might be until I actually NEED to reuse it. Otherwise it often seems like "premature optimization" trying to generalize a routine that I'm not even sure will ever get used anywhere else.

In my experience, the drive to make things reusable from the start ends up delaying projects to a point where they might just not get done.

I also refactor for the sake of readability (and urge my co-workers to do the same). Of course, this might mean I'm a bad programmer and I shouldn't ever get 6 levels deep in logic in the first place...

I always had the same experience getting TIE Fighter to run. Mostly it was a combination of LH's and DOS=HIGH,UMB which did the trick.

That and a trial and error process of reordering CONFIG.SYS and AUTOEXEC.BAT entries along with interactive boot which always reminded me of that scene from Apollo 13 when they are trying to determine the powerup sequence for the command module.

Wow, looks like they've fixed most of the problems I had with it in the past. The one thing I still miss from yakuake is to be able to select split-panes by numeric hotkey. Seems like you can only do it for separate tabs and windows, but my preferred workspace is a 2x2 visor window.

There's a feature request open for this. Haven't figured out the details yet, but I want to make it easy to assign a keystroke to a session (like how RTS games let you define groups of vehicles/soldiers). Maybe in 1.1...

Probation/parole/bail jumpers

House arrest

Prison education is pretty common

Granted, not everyone can leave jail. But take a boarding school and a minimum security prison and you're getting pretty close to the same thing.

If you drop out of school, you simply don't get a degree. If you jump bail, you get more jail time. And you're reaching to consider house arrest the same as home schooling. As for prison education, that's commonly available, but far from the purpose of prison. And boarding schools are private, there is only one public boarding school in the US, and it only has 80 students.

So your analogies don't exactly work. I would suggest reading the work of John Taylor Gatto, A.S. Neil, Francisco Ferrer, and Paulo Freire, though, if you're interested in critiques of education systems and their alternatives.