Real Programmers

[ChatIndia]

- Real programmers don't write specs. Users should consider themselves lucky to get any programs at all and take what they get.


- Real programmers don't comment their code. If it was hard to
write, it should be hard to read.


- Real programmers don't write application programs, they pro-
gram right down on the bare metal. Application programming
is for feebs who can't do systems programming.


- Real programmers don't eat quiche. Real programmers don't even know how to
spell quiche. They eat Twinkies, Coke and palate-scorching Szechwan food.


- Real programmers don't draw flowcharts. Flowcharts are, after all, the
illiterate's form of documentation. Cavemen drew flowcharts; look how
much it did for them.


- Real programmers don't read manuals. Reliance on a reference is a hallmark
of the novice and the coward.


- Real programmers programs never work right the first time.
But if you throw them on the machine they can be patched
into working in only a few 30-hours debugging sessions.


- Real programmers don't use Fortran. Fortran is for wimpy engineers who
wear white socks, pipe stress freaks, and crystallography weenies. They
get excited over finite state analysis and nuclear reactor simulation.


- Real programmers don't use COBOL. COBOL is for wimpy application
programmers.


- Real programmers never work 9 to 5. If any real programmers
are around at 9 am, it's because they were up all night.


- Real programmers don't write in BASIC. Actually, no program-
mers write in BASIC, after the age of 12.


- Real programmers don't document. Documentation is for simps
who can't read the listings or the object deck.


- Real programmers don't write in Pascal, or Bliss, or Ada, or
any of those pinko computer science languages. Strong typing
is for people with weak memories.


- Real programmers know better than the users what they need.


- Real programmers think structured programming is a communist
plot.


- Real programmers don't use schedules. Schedules are for man-
ager's toadies. Real programmers like to keep their manager
in suspense.


- Real programmers think better when playing adventure.


- Real programmers don't use PL/I. PL/I is for insecure momma's boys
who can't choose between COBOL and Fortran.


- Real programmers don't use APL, unless the whole program can be written
on one line.


- Real programmers don't use LISP. Only effeminate programmers use more
parentheses than actual code.


- Real programmers disdain structured programming. Structured programming
is for compulsive, prematurely toilet-trained neurotics who wear neckties
and carefully line up sharpened pencils on an otherwise uncluttered desk.


- Real programmers don't like the team programming concept. Unless, of
course, they are the Chief Programmer.


- Real programmers have no use for managers. Managers are a necessary evil.
Managers are for dealing with personnel bozos, bean counters, senior
planners and other mental defectives.


- Real programmers scorn floating point arithmetic. The decimal point was
invented for pansy bedwetters who are unable to "think big."


- Real programmers don't drive clapped-out Mavericks. They prefer BMWs,
Lincolns or pick-up trucks with floor shifts. Fast motorcycles are
highly regarded.


- Real programmers don't believe in schedules. Planners make up schedules.
Managers "firm up" schedules. Frightened coders strive to meet schedules.
Real programmers ignore schedules.


- Real programmers like vending machine popcorn. Coders pop it in the
microwave oven. Real programmers use the heat given off by the cpu.
They can tell what job is running just by listening to the rate of popping.


- Real programmers know every nuance of every instruction and use them all
in every real program. Puppy architects won't allow execute instructions
to address another execute as the target instruction. Real programmers
despise such petty restrictions.


- Real programmers don't bring brown bag lunches to work. If the vending
machine sells it, they eat it. If the vending machine doesn't sell it,
they don't eat it. Vending machines don't sell quiche.

Is it ture? :wink:

 

[essellar]

"Real programmers" are Mel.

Most of what's listed in your posting is what we'd consider "antipatterns" of programming (things one does that are antithetical to good practice). The problem, of course, is that there have been so many different versions of "best practices" in different environments over the years that almost every real "real programmer" can find one or two things on the list to agree with (and a few more that are deeply and personally insulting).

For instance, I prefer dynamically and weakly typed languages that permit a good deal of functional programming. That is to say that I want the code that I write to be as versatile as possible -- a variable will contain precisely what I put into it, and that may mean a number at one point, a string at another, or an object representing the sum total of all of the data I have about a particular user, and the same bit of code ought to be able to handle it ("the same code" being a rather superficial grammar which hides away some rather hairy abstractions at a much lower level). And I want my code to be able to write its own code when it has to. (Lisp, as it happens, is one of the best languages for writing code of that sort, even if it does mean dangerously depleting the world's supply of parentheses. JavaScript, and to a lesser extent, PHP and VBScript, also allow such shenanigans, but since they're often used by novice programmers, a lot of the example code you'll find in the wild is, um, less than admirable.) There are severe dangers attached to that mode of programming, though, and it's not something I can hand over to a complete novice for maintenance.

For that reason, other people prefer statically and strongly typed languages (a variable can only ever contain a value type that it was specifically declared to contain somewhere in the code). There are no surprises, and it's easy to catch potential mistakes in the compiler or editor -- but for a system that going to be large and complex, it means there will be a lot more moving parts to keep track of. So you gain safety and provability at the expense of (programmer-facing) complexity.

There is one universal truth in the list, though -- real "real programmers" don't trust floating point numbers as far as you can toss a bull elephant left-handed.