
Quasi-cranks - fogus
http://funcall.blogspot.com/2010/05/quasi-cranks.html
======
alanh
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."

------
sumeeta
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_.

~~~
jmillikin
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.

