What's your favourite quote about programming? [closed]

Question 1

What's your favourite quote about programming?

One quote per answer, and please check for duplicates before posting!

Question 2

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

— Brian W. Kernighan

Question 3

Everytime I'm writing some clever bit of code, I remind myself of this rule and look back over it to see if I can't do things in a simpler way that will be easier to maintain later, or at least add some more comments.

Question 4

A corolloary of an otherwise true maxim: Don't forget that a diagram can increase your brain power. You can swap out "remember structure of big thing" to nonvolatile paper.

Question 5

I love the quote but the implication is that we should at most put 50% of our effort into coding in the first place.

Question 6

I think the implication is that you should avoid that programmer's urge to use the 'clever' way to do something when the slightly longer, more obvious way of doing something works just fine.

Question 7

But what if it's "perfect" code? There's no way to "debug" that.

Question 8

Walking on water and developing software from a specification are easy if both are frozen.

— Edward V Berard

Question 9

Quote of the year, I'm gonna use this one

Question 10

I hate this one. It's never the case, so who cares?

Question 11

It always takes longer than you expect, even when you take into account Hofstadter's Law.
— Hofstadter's Law

Question 12

Brain stack overflow.

Question 13

@Joe D: I'm curious how you'd rewrite a recursive English sentence into a single non-recursive sentence.

Question 14

It may converge for sufficient small values of "longer"

Question 15

+1 - I'm proud to count myself among the top billion programmers along with Douglas Hofstadter.

Question 16

@g.f: When it's transformed into defining the source afterwards (with a dash), the leading introduction isn't warranted ("A: Blah." -> "Blah. -- A"). This isn't removing part of the quote.

Question 17

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

— Rick Osborne

Question 18

it seems I keep ending up maintaining code that I wish I knew where the creator lived, but its probably a good thing I don't.

Question 19

Brings new meaning to the term "killer app." I seem to always end up maintaining the psychopath's code after he's incarcerated.

Question 20

@webbiedave You work on ReiserFS? :)

Question 21

The company must really hate you if the killer got your job.

Question 22

You can have the project:

Done On Time

Done On Budget

Done Properly

Pick two.

— Unknown

Question 23

en.wikipedia.org/wiki/Project_triangle

Question 24

Reminds me of a similar triangle, but with women. "You can have a girlfriend that: Is smart, is attractive, has a good personality."

Question 25

Don't forget that exceptions do exist, though they're rare - don't count on it.

Question 26

@Maxpm: The version I heard was "The 4 S's: Smart, Sexy, Sane, Single. Pick 3."

Question 27

So, when there are no constraints on time and budget you cannot do it properly. Good to know.

Question 28

Some people, when confronted with a problem, think "I know, I'll use regular expressions."
Now they have two problems.

— Jamie Zawinski

Question 29

A timeless classic

Question 30

Some people, when confronted with a problem, think "I know, I'll use <some problem solving implementation>." Now they have two problems.

Question 31

Some people when confronted with a problem don't think, they just post on StackOverflow

Question 32

Some people don't understand regular expressions, and hate them because others do.

Question 33

@Yar - I've never found the syntax obtuse personally, and the density is a good thing. Why express something like a pattern match in a more verbose format? Where clarity is required for something complicated, the extended mode can be used with comments.

Question 34

In theory, there is no difference between theory and practice. But, in practice, there is.

— Jan L. A. van de Snepscheut

Question 35

I've also heard "The difference between theory and practice is smaller in theory than in practice."

Question 36

Roger Pate's formulation is the one I heard, written by Olin Shivers in "History of T". Paul Graham talks about it here: paulgraham.com/thist.html

Question 37

I'd say if a theory doesn't translate to practice, then the theory is simply incomplete.

Question 38

You can use an eraser on the drafting table or a sledgehammer on the construction site - Frank Lloyd Wright

Not exactly a programming quote but it most certainly applies.

Question 39

Highly applicable IMO

Question 40

Luckily for us when most software goes wrong it doesn't collapse and kill people.

Question 41

Except when it blows up an Ariane 5 (Flight 501), or doses people with lethally high levels of radiation...

Question 42

Ironically, I believe many of Frank Lloyd Wright's more convoluted buildings have fallen into disrepair.

Question 43

@TomWij, @Walter, @Roger: Please refrain from dirtying this site with your metatalk. If I wanted to hear bickering, I would visit meta.stackoverflow.com. This is where you should be having this fascinating and timeless conversation.

Question 44

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

— Rick Cook

Question 45

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
— Bill Gates

Question 46

-- Bill Gates (softwarequotes.com/printableshowquotes.aspx?id=579)

Question 47

This is true on multiple levels. A gem.

Question 48

The key difference being, of course, that the aircraft's final weight is known while the software's final LOC count is unknown.

Question 49

So why do most Microsoft products give me this feeling that I'm chained by my foot to an airplane that is struggling to get off the runway?

Question 50

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

— Leon Bambrick (@secretGeek)

(Actually, everything from http://q4td.blogspot.com/search/label/programming seeing as I curate the list.)

Question 51

I've never seen a quote point out how difficult naming things can be. I feel a sudden solidarity.

Question 52

That's 3 things. The first two are the original quote from Phil Karlton. @CodexArcanum. Naming things well is the trick.

Question 53

@StuperUser whooosh! you missed the joke!

Question 54

Took two seconds to get that after you pointed that out. Herp derp.

Question 55

Nine people can't make a baby in a month.
— Fred Brooks, The Mythical Man-Month

Question 56

technically: 18 people can't make a baby in a month

Question 57

@HereBeWolves or 10

Question 58

What's wrong with 1 guy and 8 ladies? Sounds just about right to me.

Question 59

If we go for twins or triplets we need fewer ladies.

Question 60

While the first baby will suffer 9 months latency, proper pipelining will continue to deliver 1 per month...

Question 61

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
— Donald Knuth, Structured Programming with go to Statements, JACM Computing Surveys, Vol 6, No. 4, Dec. 1974, p.268

This is extracted from the below two paragraphs, which not only say why he comes to the above conclusion, but gives information on how to avoid this mistake:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. (…)

Question 62

@Roger Pate: I suspect you're right, most people don't realize there is more to the quote.

Question 63

Hope you don't mind that I included a bit more. I think it's really important and maybe this will encourage more to read the full paper. :)

Question 64

@Roger Pate:Not at all!

CodexArcanum – CodexArcanum · Answer 1 · 2010-09-01 20:15:18Z

231

votes

+100

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

— Brian W. Kernighan

What's your favourite quote about programming? [closed]

166 Answers 166

Linked

Hot Network Questions