Page MenuHomePhabricator

Programming Wisdom
Updated 2,644 Days AgoPublic

"I checked it very thoroughly," said the computer, "and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you've never actually known what the question is." -Deep Thought, Hitchhiker's Guide to the Galaxy by Douglas Adams

This is a running list of relevant programming wisdom for all who work at MousePaw Games to benefit from. [sarcasm]May it be a beacon of light for generations to come.[/sarcasm]


These are selections from the famous Jargon File, also known as Eric S. Raymond's New Hacker's Dictionary. You can access the full dictionary here.

Bohr bug, n

A repeatable bug; one that manifests reliably under a possibly unknown but well-defined set of conditions.
Jargon File

heisenbug, n

A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.)
Jargon File

mandelbug, n

A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a Bohr bug, rather than a heisenbug.
Jargon File

schroedinbug, n

A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years.
Jargon File

Ninety/Ninety Rule, n

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Jargon File

Laws of Computer Science

The Cathedral and the Bazaar by Eric S. Raymond

  1. Every good work of software starts by scratching a developer's personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. Plan to throw one [version] away; you will, anyhow. (Copied from Frederick Brooks' The Mythical Man-Month)
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Homesteading the Noosphere by Eric S. Raymond

3 Taboos of Hacking

  1. There is strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and requires renaming. Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the form. (This would generally be too confusing or difficult to be practical.)
  2. Distributing changes to a project without the cooperation of the moderators is frowned upon, expect in special cases like essentially trivial porting fixes. Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches.
  3. Removing a person's name from a project history, credits, or maintainer list is absolutely not done without the person's explicit consent. Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own.

How Fine a Gift?

There are consistent patterns in the way the hacker culture values contributions and returns peer esteem for them.

  1. If it doesn't work as well as I have been led to expect it will, it's no good - no matter how clever and original it is.
  2. Work that extends the noosphere is better than work that duplicates an existing piece of functional territory. (Duplicating the functions of existing closed software counts as highly as original work if by doing so you break open a closed protocol or format and make that territory newly available.)
  3. Work that makes it into a major distribution is better than work that doesn't. Work carried in all major distributions is most prestigious.
  4. Utilization is the sincerest form of flattery - and category killers are better than also-rans.
  5. Continued devotion to hard, boring work (like debugging, or writing documentation) is more praiseworthy than cherrypicking the fun and easy hacks.
  6. Nontrivial extensions of function are better than low-level patches and debugging.
Last Author
Last Edited
May 19 2015, 7:49 PM

Document Hierarchy

Event Timeline

jcmcdonald edited the content of this document. (Show Details)
jcmcdonald edited the content of this document. (Show Details)