I was in a third-year group programming class in university. We were tasked with creating a web-accessible system for administrators and end users of an imaginary highway speed pass system.

Myself and another experienced member outlined a general strategy to the group: MySQL data store wrapped by business rules enforced by a server-side component accessed via API for a PHP-based web app. Then we began outlining major classes and objects: Models for data, an API helper object.

Everyone was on the same page, but for a certain "J. J.," whose contribution was: "No, we should only have four classes."

"Why?"

"Because we only have four kinds of users."

"But we just said we'll be using an object to wrap the API —"

"Yeah, that should be part of each user."

It’s this way for anyone who’s good or bad at anything.

If you’re not good, you’ll be confused and clumsily try to get the results you want. If you’re good, you actually understand what you’re doing and make deliberate strokes.

Being a crank doesn't just mean somebody's inexperienced, it means their thought processes are unusually flawed. Sit a normal person down in front of a computer and tell them to write code, and you'll end up with a typical spaghetti-code swamp. But it's a common kind of swamp -- it'll have global variables, no error handling, lots of redundant code, but fundamentally some logical structure will be present.

In contrast, tell a crank to write code, and you'll end up with the programming equivalent of Finnegan's Wake (or, if you're unlucky, Timecube). Execution paths meander and ultimately lead nowhere; comments which are not just wrong, but bear no relation to any nearby code; often, remarks that the compiler is wrong and only the crank is aware.

Crank code can be amusing to read, but I can't imagine dealing with it in a professional environment.